Login
Newsletter
Werbung

Thema: Debian diskutiert über ein Anwenderarchiv

41 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von Anonymous am Mo, 8. April 2019 um 10:12 #

... so alt sind die Debian-Anwender doch gar nicht, dass man sie archivieren müsste ;)

1
Von Josef Hahn am Mo, 8. April 2019 um 10:20 #

Zuerst schließe ich mich dem Vorredner an: Ich bin doch noch garkein Fall für's Archiv! ;)

Zum Thema: Zu meiner Arch-Zeit habe ich nur selten AUR-Pakete installiert. Ansonsten war mir das zu "weit weg". Ich hatte keine Lust auf schlechte Qualität, im Extremfall ein verzogenes System; und bezüglich Vertrauenswürdigkeit ist das halt auch wieder ein Meter weiter weg, als die Distribution selbst.

Dabei hatte ich sogar einmal gaanz kurz yaourt. ;)

  • 0
    Von linux-nutzer am Mo, 8. April 2019 um 12:35 #

    Jetzt mal mal nicht den Teufel an die Wand! Wenn man sich an gewisse Grundregeln beim Installieren von Paketen aus'm AUR hält, dann ist das AUR durchaus sinnvoll zu gebrauchen. Die wichtigste Grundregel ist, sich den PKGBUILD (und ggf. install.sh usw.) durchzulesen und ggf. zu bearbeiten, bevor man selbst oder der AUR-Helper das Paket baut. yaourt verletzt diese Regel, da es erst den PKGBUILD sourced und dich dann fragt, ob du den PKGBUILD lesen/bearbeiten möchtest.

    • 0
      Von Tamaskan am Mo, 8. April 2019 um 14:15 #

      yaourt wird aus diesen und anderen Gründen auch schon lange nicht mehr empfohlen - ich glaube es wurde nur so populär, weil es bei manchen Arch Derivaten standardmäßig installiert war. pikaur oder yay sind bessere Alternativen. Der "sauberste", wenn auch umständlichere Weg sind die aurutils, da setzt man ein eigenes Repository auf und baut alle Pakete in einer chroot-Umgebung.

      Ich finde das AUR wesentlich vertrauenswürdiger als Fremdquellen die Binärpakete anbieten. Meistens braucht man sowieso Software, die nicht im Repository ist, sodass man um das Thema nicht herum kommt. In Binärpaketen kann man aber viel leichter Malware verstecken, und außerdem ist man vom Betreuer abhängig, dass er neue Versionen paketiert.

      Ein PKGBUILD kann ich selbst verstehen und ggf. selbst anpassen und damit auch neue Versionen der Software bauen - meist muss man ja nur die Versionsnummer inkrementieren und die URL zum Quelltext-Archiv anpassen.

0
Von Neuling am Mo, 8. April 2019 um 11:35 #

Spotify oder Discord mal als Beispiel. Ein Archiv, eine Version, immer aktuell und läuft auf jeder Distribution.flatpak install XXX Und fertig. Das System selbst bleibt ja unangetastet. Verstehe ich nicht wieso man jetzt ein ähnliches Archiv aufbauen will wie das AUR. Das macht doch nur Probleme wenn größere Aktualisierungen anstehen.

  • 0
    Von linux-nutzer am Mo, 8. April 2019 um 11:51 #

    Ich weiß nicht so ganz, aber Flatpak scheint mir jetzt nicht so das Nonplusultra zu sein:

    'Ever opened an image in flatpak Gimp? The criticial vulnerability "shell in the ghost" was fixed in flatpak about one month after linux distributions.' — https://flatkill.org

    Fairerweise muss man sagen, dass dir das auch beim AUR passieren kann.

    'And it's not only about these security problems. Running KDE apps in fakepak? Forget about desktop integration (not even font size). Need to input Chinese/Japanese/Korean characters? Forget about that too - fcitx has been broken since flatpak 1.0, never fixed since.' — https://flatkill.org

    • 0
      Von Neuling am Mo, 8. April 2019 um 13:35 #

      Hmm ja war auch nur ein Beispiel. Ich stecke nicht so tief in der Materien drinne. Ich fand das nur damals unter Manjaro wesentlich einfacher so Software zu installieren, als über das AUR. Jetzt wieder unter XUbuntu funktioniert das genauso gut.

      • 0
        Von Tamaskan am Mo, 8. April 2019 um 14:23 #

        Flatpak und Snaps haben den Nachteil (oder Vorteil, wie man es sieht), dass diese nicht ins System integriert sind, sondern davon abgeschottet. Ich habe mal versucht, den neuen Personalausweis unter Ubuntu mit der AusweisApp zu benutzen. Jemand hat ein Snap dafür gebaut, aber das erhält keinen Zugriff auf meinen Kartenleser, weil der einen Zusatztreiber braucht, der nicht im Snap enthalten ist. Unter Arch Linux mit der aus dem AUR gebauten AusweisApp läuft alles. Ein anderes Problem sind Themes oder Schriftarten, die aufgrund der Isolation nicht verfügbar sind. Die Sicherheitsprobleme wurden ja schon angesprochen - ein Flatpak/Snap enthält quasi ein komplettes Linux-System das separat gepflegt/administriert werden muss.

    0
    Von Josef Hahn am Mo, 8. April 2019 um 11:51 #

    Vielleicht lehne ich mich jetzt zu weit aus dem Fenster, aber ich vemute, bei Debian stehen so Bärendienste wie Spotify, Discord und eure sonstigen WhatsApps nicht direkt ganz oben auf der Prioritätenliste. Es ging bei dieser Überlegung wahrscheinlich nicht darum, euch die Skype-Installation zu erleichtern?!

    1
    Von Oiler der Borg am Mo, 8. April 2019 um 14:50 #

    Weil es so eine widerliche 5chei55e wie MSI-Installer ist und mittelfristig auch die gleichen fatalen Auswirkungen aufweisen wird! :oops:

    • 0
      Von Flatpak-Skeptiker am Mo, 8. April 2019 um 15:28 #

      Kannst Du das bitte näher ausführen. Hatte auch ein komisches Gefühl als Flatpak noch zusätzliche Paket installieren wollte, und dazu mein root password brauchte. Habs dann besser gelassen...

      • 0
        Von Ghul am Di, 9. April 2019 um 11:53 #

        Wenn der Flatpack Installer nicht Teil des Flatpack Pakets ist, sondern von der Distri geliefert wird und der dann wie ein Paketprogramm die Dateien dann nur in das richtige Verzeichnis kopiert und dabei eine chroot Umgebung oder ähnliches verwendet wird, dann sollte es gehen, so ein Ding mit root Rechten zu installieren.

        Die Probleme liegen in dem Fall dann eher in den mitgeliefrten Libs, die uralt und voller Sicherheitslücken sein könnten. So wie bei einigen Open Source Tools unter Windows geschehen.

        Oder die Binaries sind nicht vertrauenswürdig und brechen aus ihrer Sandbox aus. Dieses Szenario wäre auch denkbar.

0
Von Anon am Mo, 8. April 2019 um 12:57 #

Ich fände ein Archiv im anderen Sinne besser. Alles was dem Pattern Simple* folgt, ab ins Archiv (Müllhalde). Das sind dann irgendwelche Studi- oder Ein-Mann-Projekte, die Niemals hinein geraten sollten.

Als nächster Schritt ein Filter auf alle Pakete, dieseit mehr als 2 Jahre kein Commit hatten. Diese gehören ebenfalls in die Tonne.

Man muss so langsam die künstlich aufgeblasene Paketzahl auf ein realistisches Maß von < 1000 drücken.

Leute die nach sinnvollen Paketen suchen verzweifeln nur an solchem Müll.

  • 0
    Von Ghul am Mo, 8. April 2019 um 13:33 #

    Als nächster Schritt ein Filter auf alle Pakete, dieseit mehr als 2 Jahre kein Commit hatten. Diese gehören ebenfalls in die Tonne.

    Wann war der letzte commit zu cp und mkdir?

    Und schwupp, auf deinem System nicht mehr vorhanden.

    • 0
      Von Anon am Mo, 8. April 2019 um 15:27 #

      Zunächst einmal werden diese Teile öfters aktualisiert als du denkst. Außerdem habe ich nicht gesagt, dass alle Pakete weg müssen, sondern der große Teil. Es gibt eine gute kritische Masse diesem Müllhafen.

      • 0
        Von Ghul am Mo, 8. April 2019 um 16:45 #

        Du hast gesagt, das alles, was in 2 Jahren keinen commit erhält weg muss und ich habe dir anhand von Beispielen aufgezeigt, wie blöd diese Idee ist.

        Manche Software braucht in Jahren kein Codeänderung, weil sie einfach funktioniert. Die würdest du mit deiner Regel rausschmeißen obwohl sie vielfach benutzt wird.

        Es gibt eine gute kritische Masse diesem Müllhafen.

        Damit machst du den größten Vorteil von Debian kaputt.
        Es hat deutlich mehr Pakete und somit Software als alle anderen Distributionen im Repository.

        Wenn du 80 % davon wegschmeißt, dann kann man auch genauso gut zu einer anderen deutlich kleineren Distribution wechseln und schon ist die Nutzerbasis kleiner und der Support noch schlechter.

      0
      Von linux-nutzer am Mo, 8. April 2019 um 16:09 #

      Keine Ahnung, aus welchen Paketen "cp" und "mkdir" auf deinem System kommen, bei mir kommen die aus dem Paket "coreutils" und das hatte laut meinem Paketmanager Anfang März einen Versionssprung von 8.30 auf 8.31.

      • 0
        Von Ghul am Mo, 8. April 2019 um 16:46 #

        Es ist ein Beispiel welches für viele andere Software stehen kann.
        Abstraktes Denken ist somit nicht deine Stärke, wenn du das nicht gemerkt hast.

        • 0
          Von linux-nutzer am Mo, 8. April 2019 um 17:12 #

          Deine Aussage ist mir schon klar, aber du hast halt einfach ein schlechtes Beispiel gewählt. Eins, was deine Aussage nicht unterstützt, da die coreutils nach wie vor weiterentwickelt werden.

          • 0
            Von Ghul am Mo, 8. April 2019 um 18:40 #

            Dann guck mal genau hin, der eigentliche Quellcode von mkdir wurde seit Nov 2016 nicht mehr angerührt.
            Das sind mit 2 Jahren und 5 Monaten mehr als 2 Jahre.

            mkdir.c

            Die Änderung der Jahreszahl und die Änderung der URL von http nach https zählt nicht.

            • 0
              Von Ghul am Mo, 8. April 2019 um 18:41 #

              Ergänzung:

              Die Änderung der Jahreszahl und die Änderung der URL von http nach https

              in einem Kommentar

              zählt nicht.

              0
              Von klopskind am Di, 9. April 2019 um 12:17 #

              0. GNU coreutils ist nicht die einzige Implementierung von cp(1) und mkdir(1) in Debian. Debian verwendet standardmäßig auch die Busybox coreutils, z.B. im initramfs.

              1. GNU coreutils cp(1) erfüllt Ihre suggerierte Behauptung (s.o.), die letzte Änderung läge mehr als 2 Jahre zurück, jedenfalls nicht, siehe hier. Schade, dass Sie das unerwähnt lassen.

              Übrigens erfüllt Busybox cp(1) diese Behauptung ebenfalls nicht, siehe hier

              2. Busybox mkdir(1) enthält - entgegen Ihrer Behauptung - eine signifikante Änderung, die weniger als zwei Jahre alt ist.

              3. Nun zu Ihrem angeblichen Beleg:
              GNU coreutils mkdir(1) ist ein Kompilat, welches Binärcode enthält, und aus mehr Quelltext generiert wurde, als die von Ihnen erwähnte Datei direkt enthält. Deshalb müssten Sie fairerweise auch Änderungen des per #include (möglicherweise rekurisv) eingebundenen Quelltextes berücksichtigen.
              Haben Sie das getan?
              Offensichtlich nicht, denn GNU coreutils mkdir(1) bindet ein und verwendet Quelltext aus mkdir-p.c in GNU coreutils gnulib. Letzte signifikante Änderung ist vom 14.12.2018, d.h. jünger als zwei Jahre.

              Damit wäre bewiesen, dass Ihre Behauptung falsch ist.

              4. Sie schränken Ihre Behauptung (s.o.), die letzte Änderung läge mehr als 2 Jahre zurück, plötzlich weiter ein - zu Ihren Gunsten. Ich zitiere:

              Die Änderung der Jahreszahl und die Änderung der URL von http nach https zählt nicht.
              Wer die Regeln macht, gewinnt auch das Spiel. Also halten Sie sich in Zukunft doch bitte an Ihre eigenen Spielregeln.

              • 0
                Von Ghul am Di, 9. April 2019 um 13:58 #

                0. GNU coreutils ist nicht die einzige Implementierung von cp(1) und mkdir(1) in Debian. Debian verwendet standardmäßig auch die Busybox coreutils, z.B. im initramfs.

                Und jetzt?
                Der User kriegt GNU als default.

                4. Sie schränken Ihre Behauptung (s.o.), die letzte Änderung läge mehr als 2 Jahre zurück, plötzlich weiter ein - zu Ihren Gunsten.
                Nö, Kommentare sind kein Code.
                Sie verändern das Programm nicht.

                • 0
                  Von klopskind am Di, 9. April 2019 um 15:07 #

                  Und jetzt?
                  Der User kriegt GNU als default.
                  Was immer auch "default" bedeuten mag; installiert sind unter Debian standardmäßig beide Implementierungen, und aus Ihrer Frage wird nicht klar, welche Implementierungen gemeint sind.

                  Punkt 0 war lediglich ein Hinweis darauf, dass Ihre oben gestellte Frage nicht ganz klar formuliert ist, da eine Antwort jener von der Wahl der Implementierung abhängt.

                  Nö, Kommentare sind kein Code.
                  Sie verändern das Programm nicht.
                  Das ist zwar alles korrekt, aber Sie sprachen von "commit". Strenggenommen ist jede Änderung des Quellverzeichnisses ein "commit", auch reine Kommentaränderungen. Gängige Definitionen finden Sie hier oder hier.

                  Wie dem auch sei: Ihnen ist sicherlich nicht entgangen, dass ich auf diese Pedanterie in meiner Widerlegung (Punkte 0-3) Ihrer unbelegten Behauptung (s.o.) keinen Bezug genommen habe, indem ich annahm, dass Sie mit "commit" signifikante Quelltextänderungen gemeint hatten. Die von mir angeführten Belege stützen sich auf Verweise zu Quelltextänderungen, die den effektiven Programmablauf verändern, und keine Änderungen, die ausschließlich Kommentare oder Stylekorrekturen betreffen.

                  Kurzum, ich wollte Sie mit Punkt 4 lediglich darauf aufmerksam machen, dass Sie fair spielendiskutieren sollten.

                  • 0
                    Von Ghul am Di, 9. April 2019 um 15:30 #

                    Pedanterie scheint Ihnen eine sehr wichtige Sache zu sein.

                    Wieso durchforsten Sie in ihrer Freizeit nicht einfach mal den Quellcode von ein paar Open Source Projekten und machen sich damit nützlich?
                    Quellcode lesen scheinen Sie ja zu können.

                    • 0
                      Von klopskind am Di, 9. April 2019 um 16:07 #

                      Die eigentliche Frage ist, warum Sie das nicht schon vor mir getan haben.

                      Ihr Kommentar ist an Dreistigkeit kaum zu überbieten und widerspricht zudem Ihrem Schlusswort Ihres Kommentars unten (zeitlich vor dem Kommentar hierüber). Es scheint mir viel eher so, als wären Sie die Person, die hier suchten Streit.
                      Ich wünsche Ihnen ein schönes Leben noch!

                      • 0
                        Von Ghul am Di, 9. April 2019 um 16:21 #

                        Pedanterie ist beim Coden eine gern gesehene Eigenschaft.

                        Sie könnten die geschweiften Klammern bei if und while Schleifen gerade rücken, zusehen, dass die Werte von Variablen, die untereinander aufgelistet werden, schön in einer Spalte dargestellt werden und gesetzte Tabs aus dem Quellcode entfernen und durch Leerzeichen ersetzen.

                        Natürlich könnten sie auch Variablen bessere aussagekräftigere Namen geben, deutsche Kommentare ins englische übersetzen oder noch besser, Fehler suchen, auf die sonst keiner Lust hat.

                        Das Gebiet ist da sehr groß.
                        Da können Sie sich also richtig austoben.

          0
          Von klopskind am Di, 9. April 2019 um 10:33 #

          Es ist ein Beispiel welches für viele andere Software stehen kann.
          Ja, das ist es sicherlich. Und ich bin mir sicher, dass sich ein Beispiel finden lässt, wo die Umsetzung der oben erwähnten Vorschläge nicht unproblematisch wären.

          Aber wenn Sie Ihren Standpunkt klar kommunizieren wollen, hätten Sie ein geeigneteres Beispiel wählen und dies mit konkreten Belegen untermauern können. Das hätte Ihnen diese Diskussion erspart.

          Abstraktes Denken ist somit nicht deine Stärke, wenn du das nicht gemerkt hast.
          Jetzt kommen Sie mal wieder runter von Ihrem hohen Ross! Das nimmt ja Formen an... wie im Kindergarten. Suchen Sie Streit?

          • 0
            Von Ghul am Di, 9. April 2019 um 12:01 #

            Aber wenn Sie Ihren Standpunkt klar kommunizieren wollen, hätten Sie ein geeigneteres Beispiel wählen und dies mit konkreten Belegen untermauern können. Das hätte Ihnen diese Diskussion erspart.

            Es hätte mich Zeit gekostet, extra so ein Paket rauszusuchen.
            Vom Kontext war klar, wo die Vorschläge hinführten, daher waren die Beispiele ausreichend und mkdir erfüllt sie sogar.

            Das Problem liegt da eher an den Diskussionspartnern die nicht mitdenken oder alternativ sich mit Vorsatz um etwas dagegen sagen zu können, als Problem vor dem Bildschirm hinstellen.

            Jetzt kommen Sie mal wieder runter von Ihrem hohen Ross! Das nimmt ja Formen an... wie im Kindergarten. Suchen Sie Streit?
            Ich gehe davon aus, dass auf einer IT Newsseite die Leute sehr genau wissen was sie sagen und wenn sie es dann trotz besseres wissen trotzdem streiten kommt halt die entsprechende Antwort.

            Und ja, natürlich wussten sie es, ein echter Anfänger hätte nämlich nicht gemerkt, das mkdir und mv gar nicht als eigenständiges Paket kommen. Also wusste man es und hat gegen besseren Wissen mit Vorsatz dagegen geredet um einfach zu streiten.
            Den Schuh solltest du also dem zuschieben, dem ich entsprechend geantwortet habe.

            • 0
              Von klopskind am Di, 9. April 2019 um 13:04 #

              Es hätte mich Zeit gekostet, extra so ein Paket rauszusuchen.
              Was Sie nicht sagen... Aber dann können Sie auf der anderen Seite doch nicht erwarten, dass Ihre Einwände/Argumente für voll genommen werden.

              Vom Kontext war klar, wo die Vorschläge hinführten, daher waren die Beispiele ausreichend und mkdir erfüllt sie sogar.
              Um sicher zu gehen, ist es ratsam, im Allgemeinen davon auszugehen, dass das nicht (allen) klar ist. Insbesondere in einem Kommunikationsmedium, das im Wesentlichen auf Text, grundlegender HTML-Formatierungen und Smileysymbolen beruht. Und wenn es nur dazu dienen mag, im Anschluss sinnlose Diskussionen zu vermeiden...

              Das Problem liegt da eher an den Diskussionspartnern die nicht mitdenken oder alternativ sich mit Vorsatz um etwas dagegen sagen zu können, als Problem vor dem Bildschirm hinstellen.
              Na klar, es waren die anderen! Bloß nicht an die eigene Nase fassen und sein eigenes Handeln reflektieren!
              Ich sagte ja bereits Kindergarten...

              Ich gehe davon aus, dass auf einer IT Newsseite die Leute sehr genau wissen was sie sagen und wenn sie es dann trotz besseres wissen trotzdem streiten kommt halt die entsprechende Antwort.
              Was verstehen Sie unter Streit? Die Argumente in diesem "Streit" wurden meiner Ansicht nach bisher sachlich und unprovokant dargelegt und vorgetragen. Es gibt daher keinen Grund, selbst provokant oder unsachlich zu werden, falls ein solcher mit der Alternative des Ignorierens je bestehen mag (siehe Ihr Kommentar oben und die folgende Diskussion).

              Unabhängig davon halte ich Ihre Sichtweise für äußerst elitär und verschlossen. Das kann langfristig keine positiven Auswirkungen auf Pro-Linux haben.
              Aber Sie vermitteln mir ohnehin wieder und wieder den Eindruck, dass Sie an soetwas gar nicht interessiert sind - im Gegenteil.

              Und ja, natürlich wussten sie es, ein echter Anfänger hätte nämlich nicht gemerkt, das mkdir und mv gar nicht als eigenständiges Paket kommen. Also wusste man es und hat gegen besseren Wissen mit Vorsatz dagegen geredet um einfach zu streiten.
              Wer "man"? Und spielt das ein Rolle?

              Sie haben auf provokante und suggestive Art und Weise eine Behauptung aufgestellt und nicht belegt, siehe oben. Diese Behauptung ist von anderen berechtigterweise in Frage gestellt worden - bisher in sachlichem Ton, wie ich finde - und meinerseits sogar widerlegt worden.
              Sie brauchen sich nicht wundern, wenn Sie bekommen, was Sie verdient haben.

              Den Schuh solltest du also dem zuschieben, dem ich entsprechend geantwortet habe.
              Nein, denn dazu sehe ich bisher keinen Grund.

              0
              Von klopskind am Di, 9. April 2019 um 13:08 #

              Es hätte mich Zeit gekostet, extra so ein Paket rauszusuchen.
              Aber zum Rumpöbeln reicht die Zeit natürlich ;-)

      0
      Von klopskind am Di, 9. April 2019 um 09:48 #

      Wann war der letzte commit zu cp und mkdir?
      Die Antwort hängt von der Wahl der Implementierung ab. Unter Debian werden cp(1) und mkdir(1) standardmäßig mindestens durch GNU coreutils und Busybox coreutils implementiert.

      Und schwupp, auf deinem System nicht mehr vorhanden.
      Sie suggerieren damit, dass Sie behaupten würden, dass Implementierungen von cp(1) und mkdir(1) in Debian keine Änderungen erfahren hätten.
      Ich halte es für angebracht, dass Sie diese Aussage zunächst stichhaltig beweisen würden, bevor Sie diese in einem Argument verwenden, und falls Sie ernsthaft an einer fruchtbaren Diskussion interessiert sind.


      --
      Um Ihren Standpunkt angebrachter zu kommunizieren, versuchen Sie beim nächsten Mal, Ihre Argumente mit konkreten Belegen oder einer geeigneteren (Gegen-)Beispielen zu untermauern.

      Ihr Kommentar wirkt insgesamt eigensinnig und provokant. Sind Sie bockig? Suchen Sie Streit?

      • 0
        Von Ghul am Di, 9. April 2019 um 12:04 #

        Ich halte es für angebracht, dass Sie diese Aussage zunächst stichhaltig beweisen würden,

        Bla, bla bla.

        bevor Sie diese in einem Argument verwenden, und falls Sie ernsthaft an einer fruchtbaren Diskussion interessiert sind.
        Wenn sie mir so kommen, dann habe ich darauf keinen Bock.
        Den Rest habe ich in meinem anderen Kommentar weiter oben schon geschrieben.

        Bei ihnen wäre es also auch Vorsatz trotz besseres Wissen.
        Sie suchen Streit und darauf habe ich keine Lust.

    0
    Von klopskind am Di, 9. April 2019 um 10:20 #

    Da ist sicherlich etwas dran. Ich kann Ihre Haltung verstehen. Aber ganz so drastisch würde ich nicht vorgehen.

    Trotzdem halte ich ein feinere Abstufung der Pakete/Archive z.B. unter Berücksichtigung von Konformität (DFSG), Sicherheit, Kompatibilität, unterschiedlichen Anforderungen der Anwenderbasis (z.B. Basispakete, Systempakete, Serverpakete, Entwickler- & Sprachpakete, Pakete für Workstation & Desktop/Laptop, Erweiterungspakete, ...), und allg. Qualität für sinnvoll.
    So könnten Pakete auch für unterschiedliche Nutzer/Anwendungsfälle angepasst paketiert werden (Server, Embedded, Entwickler, Workstation, Desktop, Endanwender).

    Hier würden verschiedene Archive in gewisser Hinsicht Abhilfe schaffen. Die Frage bleibt nur, wie man das am geschicktesten plant, organisiert und umsetzt. Da exisiteren bisher verschiedene Ansätze: Debian hat bisher "nur" die Backports. Ubuntu hat die Unterscheidung mit dem Archiv namens universe und PPAs, RHEL/CentOS/SL haben EPEL und openSUSE hat das OBS und verschieden Zweige als Möglichkeit à la Backports. FreeBSD hat sein Basissystem und seine Ports.

    Die Diskussion an sich, sowie die Ideen, Vorschläge und Initiative von Herrn Mo Zhou betrachte ich daher mit großer Freude.

0
Von Ghul am Mo, 8. April 2019 um 13:40 #

Was sind eigentlich die Gründe warum noch ca. 7% der Debian Testing Pakete für AMD64 noch nicht reproduzierbar identisch baubar sind?

https://wiki.debian.org/ReproducibleBuilds

Pro-Linux
Frohe Ostern
Neue Nachrichten
Werbung