Login
Newsletter
Werbung

Thema: Debian stellt auf RPM um

29 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von Oiler der Borg am Mo, 1. April 2019 um 09:28 #
0
Von Schlumpfling am Mo, 1. April 2019 um 09:37 #

Haha, haha, haha. ('_')

In Wahrheit haben sie genug andere Stellen ...

Gerade wieder festgestellt, dass asiatische Terminals und ein Rattenschwanz an unnützen Sprachpaketen bei einer Neuinstallation mit drauf geschaufelt werden. Da frag' ich mich schon nach dem Sinn einer Sprachauswahl im Installer.

0
Von Tutnixzursache am Mo, 1. April 2019 um 10:02 #

1. Umstellung von DEB auf RPM.
2. Debian 11 schon in zwei Jahren. ;–)

0
Von Ghul am Mo, 1. April 2019 um 10:04 #

das ist der Aprilscherz.

0
Von Aprilscherzsammler am Mo, 1. April 2019 um 10:34 #
1
Von Anon am Mo, 1. April 2019 um 10:43 #

Ein gemeinsam genutzes Paketformat wäre echt top.

  • 2
    Von Andre am Mo, 1. April 2019 um 10:44 #

    ganz sicher... aber das müsste dann schon eher dpkg sein :-)

    • 0
      Von Au Backe am Mo, 1. April 2019 um 10:51 #

      Ach ja, der Windows-Troll Andre darf natürlich nicht fehlen.

      Obwohl: 1. April, das passt ja zu seinen Kommentaren.

      0
      Von blablabla233 am Mo, 1. April 2019 um 11:24 #

      Also ganz ehrlich...das NetBSD-Pkg wäre wohl das beste.

      • 0
        Von kraileth am Mo, 1. April 2019 um 13:48 #

        Im Hinblick auf die Unterstützung etlicher verschiedener Plattformen - Ja, da ist Pkgsrc ungeschlagen. Leider hat es einige Probleme:

        1) Zum einen das Paketmanagement selbst (für den Endanwender sicherlich am wichtigsten). Die Werkzeuge dafür sind von vorgestern, genaugenommen wortwörtlich aus dem letzten Jahrtausend - und nicht besonders gut gealtert. Man kann damit vernünftig arbeiten, wenn man sie kennt, aber wenn man sich ansieht, was heute (zurecht) als gegebener Standard erwartet wird, dann sind dem geneigten Nutzer die pkg_tools doch ein wenig peinlich.

        2) Die Build-Infrastruktur (für den fortgeschrittenen Anwender wesentlich). Hast Du mal Bulk-Builds durchgeführt? Auch dafür gilt das gleiche Urteil wie für das Paketmanagement im engeren Sinne: Es geht - aber es geht halt auch entschieden besser.

        3) Ports-Infrastruktur (für Entwickler / Porter): Hier, wie auch allgemein, haben die NetBSD-Leute wirklich viel geschaffen. Da muß man schon sagen: Hut ab. Leider gibt es auch da das Problem, daß Pkgsrc ein schon recht altes Projekt ist und vieles nachträglich „dazugebastelt“ wurde. Funktioniert, ist aber vielfach einfach nicht schön und unnötig aufwändig.

        Dazu kommt, daß die Unterstützung einiger der genannten Plattformen nicht mehr als ein „portability stunt“ ist. Das soll nicht zu negativ klingen, denn es hat schon etwas für sich. Man darf aber nicht erwarten, daß der Großteil der gebotenen Software auf den meisten Plattformen läuft. NetBSD ist hier ganz klar das primäre Ziel. Wenn aber jemand Pakete z.B. für AIX braucht, dann ist bestimmt Pkgsrc einen Versuch wert.

        Ein bißchen Werbung: Ravenports ist ein Projekt, welches die Stärken von Pkgsrc aufzugreifen versucht und diese mit modernen Ansätzen kombiniert. Es ist das zukünftige primäre Paketsystem von DragonFly BSD und zusätzlich auch für FreeBSD, Linux und Solaris/Illumos verfügbar (ein Bootstrap auf macOS ist erfolgt, liegt aber derzeit auf Eis). Die Paketauswahl im Repo ist noch überschaubar (ca. 3.300), dieses hält aber seit eineinhalb Jahren den Aktualitätsrekord auf Repology. Außerdem ist es Paketmanager-neutral entworfen; derzeit wird auf allen Plattformen Pkg eingesetzt, es spricht aber auch nichts dagegen, dpkg, rpm, pacman, o.ä. zur Paketverwaltung zu verwenden wenn man damit besser vertraut ist.

        Ich bin einer der als Porter daran beteiligten Personen und damit sicherlich nicht unvoreingenommen. Für Admins, die mit verschiedenen *nix-Betriebssystemen oder Distributionen arbeiten hat es aus meiner Sicht ziemlich viel Potential. Allerdings muß man zum jetzigen Zeitpunkt gestehen, daß die Linux-Unterstützung besser sein könnte (der Bootstrap erfolgte auf einem Ubuntu-System, weshalb eine halbwegs aktuelle glibc Voraussetzung ist, was z.B. CentOS derzeit ausschließt und Pkg, das auf allen anderen Plattformen läuft wie eine Eins, hat gelegentliche seltsame Macken).

        Die beiden BSDs sind mit Nutzern bereits gut vertreten, Interessenten aus dem Linuxlager (z.B. von kleineren Distris, die Schwierigkeiten haben, ihre Pakete aktuell zu halten, könnten direkt von gut gepflegten Paketbauplänen und einem modernen Buildsystem profitieren) wären gerne gesehen. Sollte jemand Fragen zum Projekt haben, immer her damit. ;)

        • 0
          Von klopskind am Mo, 1. April 2019 um 22:29 #

          Ich danke dir für den netten Kommentar.

          1. Welche Paketverwaltungssysteme außer (oder nach) Ravenports siehst du hier am ehesten auf der Höhe der Zeit ggü. pkgsrc?

          2. Ich denke auch, dass Ravenports im Linux-Ökosystem sehr viel Sinn ergeben würde, genauso wie den Aufbau der BSDs mit einer strikteren Trennung von Basissystem und Erweiterung/"Ports" in meinen Augen viel sinnvoller erscheint.
          Bietet Ravenports außer der "Portabilität" (Allgemeingültigkeit) noch andere Vorteile ggü. traditionellen Distributionen?

          • 0
            Von kraileth am Di, 2. April 2019 um 08:58 #

            Sehr gerne, freue mich über Dein Interesse!

            1) Es kommt hier natürlich sehr stark darauf an, was man sucht.

            1a) Wenn man eine gewisse Nähe zu Pkgsrc haben möchte, dann drängt sich das XBPS von Void Linux auf (der Gründer von Void und Schöpfer von XBPS ist ein früherer NetBSD-Entwickler, der sich Linux zugewendet hat, so daß die Verwandtschaft keine allzugroße Überraschung sein dürfte). Für mich als ehemaligen Archer der auch die alternative C-Bibliothek Musl sehr schätzt, ist Void überhaupt sehr anziehend (Runit scheint mir auch recht nett zu sein). Ich habe es die letzten Jahre nicht genauer verfolgt, aber in meiner Erinnerung war XBPS recht brauchbar (es war wohl mal dazu gedacht, Pkgsrc abzulösen). Verglichen mit Raven ist es aber trotzdem noch deutlich näher am etwas Altbackenen (getrennte Befehle für die Paketwerkzeuge usw.), also meiner Einschätzung nach eine gute Weiterentwicklung aber kein radikaler Neuanfang. Es ist allerdings für Portabilität entworfen und *könnte* vermutlich auch für andere Systeme verwendet werden (ist meines Wissens aber nicht ernsthaft passiert).

            1b) Wenn's minimalistisch sein soll, habe ich früher sehr gerne mit Apk von Alpine Linux gearbeitet. Unverkennbar Arch-ähnlich (APKBUILD- statt PKGBUILD-Dateien und ganz ähnlicher Aufbau), aber auf sparsam getrimmt (z.B. Subpackages "-dev" für die Header wie bei Debian anstatt wie bei Arch alles KISS-mäßig in ein Paket zu packen). Schick, sparsam, leider auch ein Exot.

            1c) Ein sehr interessanter Ansatz ist auch der Package-Manager Nix, der das Paradigma funktionaler Programmierung auf die Paketverwaltung überträgt (einfach mal kurz informieren, ist gut investierte Zeit, wenn man sich für das Thema interessiert). Für mich persönlich verliert er sich aber etwas zu sehr in Dingen, die ich als Bastler nett finde, die für mich aber am Ende des Tages wie Spielerei aussehen. Dadurch ist eine recht hohe Komplexität gegeben und mir sind z.B. die nixpkgs zu unübersichtlich, um damit intensiver zu arbeiten.

            1d) Verzicht auf vorgefertigte Binärpakete und Nutzung z.B. der FreeBSD-Ports oder von Gentoos Emerge kann für manchen natürlich auch eine Option sein. Mit etwas Aufwand lassen sich damit eigene Binärpakete schaffen und auf zahlreichen Maschinen nutzen.

            2) Als jemand, der mit heterogenen Systemen arbeitet, ist für mich der Hauptvorteil, daß ich auf den BSD- und den Linux-Kisten (verschiedene Distris) die gleichen Versionen bestimmter kritischer Software laufen lassen kann - und damit dem Wahnsinn des Versionsjungels entgehe, der droht, wenn man dazu die jeweils im Distri-Repo vorhandenen Versionen nutzt (und den Aufwand spare, alles auf den Zielsystemen selbstzubauen und zu pflegen).

            In einer homogenen Umgebung mit nur einer Linux Distri kann Raven diese Stärke natürlich nicht ausspielen. Hier würde vielleicht dafür sprechen, daß man darüber recht neue Software zusätzlich beziehen kann. Der Rabe ist nicht eifersüchtig: Alle Pakete werden standardmäßig mit Präfix /raven gebaut (könnten aber genausogut nach /opt oder dergleichen installiert werden) und kommen durch diese Parallelstruktur den Paketen der Distri nicht ins Gehege. Das kann z.B. ganz nett sein, da Raven auch die Installation z.B. mehrerer PHP-Versionen gleichzeitig unterstützt. Man kann seit kurzem sogar Pakete kombinieren, die verschiedene SSL-Bibliotheken nutzen (z.B. LibreSSL, OpenSSL 1.0.2 und OpenSSL 1.1.1)!

            Das Tooling ist aus meiner Sicht einfach großartig. Wer selbst angepaßte Pakete (z.B. anderer Prefix) bauen möchte, bekommt ein leicht zu handhabendes und gleichzeitig sehr mächtiges Werkzug an die Hand: Ravenadm.

            Es werden „Varianten“ unterstützt, d.h. eine Software kann in mehreren gängigen Kompilierzeit-Konfigurationen zur paketiert werden (z.B. eine mit minimalen Abhängigkeiten und eingeschränkten Fähigkeiten, eine Durchschnittskonfiguration und eine mit vollem Featureumfang aber vielen und schwergewichtigen Abhängigkeiten).

            --

            Theoretisch könnte man auch eine ganze Distri aufziehen, die Raven für die Paketerstellung nutzt. Als Fernziel habe ich die Idee eines „teammate Linux“ (Arbeitstitel) im Hinterkopf, einer Distribution, die darauf ausgelegt ist, sich gut in heterogene Umgebungen einzupassen. Aber das ist weit weg. Realistischer wäre es wahrscheinlich, daß eine bestehende kleine Distri Raven als Zweitpaketsystem einführt (die Arbeit für „pflegeintensive“ Programme wie Webkit-*, die verschiedenen Qt-Komponenten, LibreOffice samt Abhängigkeiten, aktuelle GCC- und LLVM-Toolchain sowie Rust usw. nicht doppelt machen zu müssen, da andere sich darum kümmern, könnte attraktiv sein).

            • 0
              Von klopskind am Di, 2. April 2019 um 14:58 #

              Hey, danke. Das klingt ja alles ganz interessant.

              1) Richtig, jedes System hat so seine besten Anwendungsfälle/-nichen.

              Manchmal beschleicht mich allerdings das Gefühl, dass die Schnittmengen der Eigenschaften & (Non-)Features sehr groß sind, und man sich dort schon Arbeit hätte sparen können.

              So haben bspw. Alpine Linux APKBUILD, Arch Linux PKGBUILD, Crux Ports, XBPS etwa den selben Fokus. Sogar Source Mage kommt dem sehr nahe, ist allerdings ohne Absicht, Binärpakete zu verteilen, entwickelt worden, und wirkt mittlerweile fast tot (siehe 1d).

              Die Verschiedenheit der Ports-Systeme der BSDs habe ich auch nie ganz nachvollziehen können. Klar müssten die Makefiles und Patches mitunter anders aussehen. Andere Software läuft mitunter gar nicht, da nötige Kernelschnittstellen o. -module fehlen.
              Aber die Werkzeuge zum bauen oder verteilen sollten doch mit minimalen Anpassungen auf einer gemeinsamen Basis stehen können, oder nicht?

              Aus der Ferne kommt mir das bei den Ravenports schon anders vor. Allein der Zustand und die Absichten hinter dem Projekt versprechen ein besseres Zusammenspiel auf verschiedenen Platformen.

              Ich will nicht sagen, dass die hier genannten Projekte nicht existieren sollten. Es geht ja meist auch darum, was man (ein/die Entwickler) selbst auf die Beine gestellt bekommt.
              Möge die bessere Lösung gewinnen - nach welchen Metriken von "besser" auch immer...

              zu 1c) Den Ansatz von Nix finde ich interessant, aber auch sehr kompliziert. Man erhält viele Garantien von diesem Ansatz. Der Preis, den man zahlt, ist allerdings enorm: Eine traditionelle, manuelle Installation eigener Software per make wird zur Qual und geht eigentlich nur mittels diverser Tricks und der Emulation einer speziellen Umgebung samt FHS usw.
              Desweiteren muss man eine (weitere) DSL lernen oder anderen beibringen. Nur kleinere Teams und Startups werden sich soetwas leisten (können).
              GoboLinux mit seinen Recipes ist ja kläglich damit gescheitert, den FHS zu revolutionieren.

              1d) Die FreeBSD Ports mag ich sehr gern. Leider ist TeXLive immer noch nicht auf dem aktuellen Stand, siehe Bug #211997.

              Gentoos Ansatz hat mich noch nie besonders umgehauen. Ich sehe die Stärken eigentlich nur beim Konzept als Metadistribution. Für mich ergibt das eigentlich nur wirklich Sinn, falls man eine größere Zahl maßangefertigter Systeme betreibt, sodass sich Skalierungseffekte ausnutzen lassen.

              Obwohl ich es nie verwendet habe, fand ich Source Mage fand schon immer ganz niedlich. Im Wesentlichen sind die Abhängigkeiten diverse Tools, die sowieso auf den meisten Systemen vorhanden sind (coreutils, Archivierungs- und Kompressionsprogramme, eine vollständige Buildtoolchain) und Bash. Sozusagen der nächste konsequente Schritt nach LFS. Interessanter Ansatz.

              1e) Was mich ggü. RPM so fasziniert, ist, dass die Abhängigkeiten, bspw. von Perl, nicht wirklich notwendig sind, Systeme mit ähnlichen Features anzubieten.
              So kommen die meisten dieser Systeme ohne viele/große Abhängigkeiten aus, und schaffen es trotzdem, mit weniger Code zum Ziel zu kommen.

              1f) Haben Sie zufälligerweise Erfahrung mit dem Open Build Service (OBS) sammeln können? Ich habe hier und da sehr positive Kurzberichte dazu lesen können.

              Die Hauptinstanz ist bekanntlich die des openSUSE-Projekts. Man kann auch eigene Instanz betreiben, was scheinbar so einige größere Projekte für sich nutzen, siehe hier.

              2) Klingt plausibel, in so einem Anwendungsfall, auf Ravenports zu setzen. Ich sehe, dass es mit den "Professional Services" auch eine Grundlage gibt, nicht nur ein weiteres Ports-/Paketprojekt zu sein. Ich wünsche dem Projekt und seinen Mitstreitern viel Erfolg.

              Ravenports ist mit Ausnahme der darunterliegenden Tools für Paketformat pkg anscheinend in Ada geschrieben. Eine interessante Wahl!

              • 0
                Von Mitzekatze gibt ein Lob aus am Do, 4. April 2019 um 08:10 #

                Was geht denn hier ab, das ist ja so interessant das hieraus ein Artikel für PL gemacht werden sollte!

                0
                Von kraileth am Do, 4. April 2019 um 09:43 #

                Wollte mich an dieser Stelle nochmal für die Antwort bedanken. Insbesondere über den „Source Mage“ war ich z.B. noch nie gestolpert.

                Bezüglich der Verschiedenheit der Ports-Systeme: Eingeführt wurde das Ports-Framework 1993 in FreeBSD 1.0 durch Jordan Hubbard. Es wurde ca. ein Jahr später von NetBSD adaptiert (und landete dadurch auch im späteren Fork OpenBSD). Zu diesem Zeitpunkt waren die Unterschiede wohl sehr gering und man tauschte sich auch aus, wodurch Erweiterungen unter NetBSD zu FreeBSD zurückflossen. Als sich dann aber unter NetBSD der Fokus verschob, trennten sich eben die Wege und man entwickelte sich wortwörtlich voneinander weg. Das führt dann dazu, daß Software, die schon ewig dabei ist, auch z.B. in den gleichen Kategorien steckt, während später hinzugefügte sich unterscheiden kann (worauf ich u.a. jedes Mal wieder reinfalle, obwohl ich es eigentlich weiß, ist, daß der Origin von Tmux unter FreeBSD sysutils/tmux ist, unter Pkgsrc aber misc/tmux!).

                Schön, daß Sie Gobo erwähnen! Ich hatte auch überlegt, es anzukratzen, habe mich aber letztlich dagegenentschieden, um den Kommentar nicht noch weiter aufzublasen. Ich fand den Ansatz auch äußerst interessant und freute mich, als das Projekt nach langem Schlaf wiedererweckt wurde - habe es aber inzwischen aus den Augen verloren.

                TeX in FreeBSD: Ja, das ist eine der großen Baustellen. Wir haben das Monster in Raven irgendwann auch noch vor uns...

                Mit SuSEs OBS habe ich nie gearbeitet. Ich finde den Ansatz gut, er ist mir aber nicht flexibel genug (da ich nicht nur mit mehreren Linux-Distris arbeite, sondern auch *BSD und Illumos in meine Planung einbeziehen möchte). Aber als das, was es ist, soll es ganz ordentlich sein.

                Zu Ada: Ja, der Hauptentwickler hat wohl ursprünglich einen NASA- / Raumfahrt-Hintergrund, wo diese Sprache bevorzugt für missionskritische Anwendungen eingesetzt wurde, wodurch er Ada genügend zu schätzen gelernt hat, daß er u.a. der Maintainer für die Ada-Compiler unter *BSD wurde. Ich selbst beherrsche kein Ada, weshalb ich mich mit Wertungen sehr zurückhalte. Aber ich erlebe immer wieder, daß viele Leute nach einem kurzen Staunen über den Praxiseinsatz des Exoten für Ravenadm das eigentlich recht gut finden.

0
Von Maxerl Moritz am Mo, 1. April 2019 um 11:01 #

Sehr gut geschrieben, ich habe es tatsächlich für mehrere Minuten lang geglaubt und war als Ubuntu-Benutzer gleich zweimal getroffen (kein DEB und kein Snap mehr) !

Ihr frechen Spitzbuben.

0
Von Atalanttore am Mo, 1. April 2019 um 15:58 #

kein Text

  • 1
    Von zxy am Mo, 1. April 2019 um 16:51 #

    Das sehe ich genauso.

    Deb ist praktisch in der Zeit stehengeblieben, rpm wurde stetig weiterentwickelt.

    So mancher Aprilscherz wurde später ja dann doch wahr.

    Es ist ohnehin sehr schade, dass Debian und Fedora nicht näher zusammenarbeiten.

0
Von ri am Mo, 1. April 2019 um 21:42 #

Ich bin beim Lesen kurz erblasst... also wirklich, damit macht man doch keine Witze.

ri

0
Von Falk am Di, 2. April 2019 um 01:07 #

Dann kann man auch gleich noch ein grafisches Verwaltungsfrontend auf Debian migrieren. Das könnte dann z.B. Yealding Advanced Superior Debian (YASD) heißen.

Pro-Linux
Frohe Ostern
Neue Nachrichten
Werbung