Mageia aufhübschen (Dandifying Mageia)

[man-draker]

Im englischen Mageia-Blog ist am 04.09.2016 eine - im ersten Anlauf für Entwickler interessante - Meldung erschienen. (https://blog.mageia.org/en/2016/09/04/dandifying-mageia/).

Dort wird darüber berichtet, dass (unter Einsatz von ziemlich viel Arbeit), das Fedora-Werkzeug DNF unter Mageia6 lauffähig gemacht wurde. DNF erledigt unter Fedora/RedHat/CentOS das, was urpmi unter Mageia tut: Wenn Programme installiert werden, sorgt es dafür, dass alle Pakete, die diese Programme benötigen mit installiert werden. Darüber hinaus verwaltet es die Aktualisierung des Systems.

Dieser mögliche Einsatz von DNF unter Mageia, erlaubt es nun, die Distribution Mageia als mögliches Ziel für das Herstellen von Paketen in MOCK einzubinden. Was ist nun MOCK? Es erledigt den Job im RedHat-Universum, den rpmbuild bei Mageia tut.

Was interessiert das den einfachen Benutzer?

Nun, es ermöglicht Entwicklern - so die Zielvorstellung - die Pakete für RedHat und Co. erstellen, auf Knopfdruck gleich welche für Mageia mit zu erzeugen. Und dies, ohne vorher eine andere Distribution starten und mit "fremden" Werkzeugen hantieren zu müssen. Die damit verbundene Hoffnung ist natürlich, dass so Pakete für Mageia entstehen, die es sonst nur für RedHat und Co. gäbe und welche sich (wie hier schon einige leidvoll erfahren haben) nur mit Verrenkungen unter Mageia installieren lassen.

Außerdem gibt es einige Werkzeuge, z.B. Spacewalk und Katello für das Paketmanagement in größeren Installationen, die mit DNF auch unter Mageia nutzbar werden.

Also dient das Projekt insgesamt dem Ziel. mehr Software unter Mageia verfügbar zu machen, ohne alles selber anpassen zu müssen.

[Latte]

Danke für die Zusammenfassung. Ich habe den Blogeintrag zwar gesehen, aber a) habe ich nicht alles verstanden und b) durch das fehlende technische Verständnis war es für mich nicht möglich, eine Übersetzung davon zu liefern...

[jkowalzik]

DNF unter Mageia, erlaubt es nun, die Distribution Mageia als mögliches Ziel für das Herstellen von Paketen in MOCK einzubinden. .......Was interessiert das den einfachen Benutzer?

Hallo!
Hört sich ja einigermaßen kompliziert an und garantiert nichts womit ich etwas anfangen könnte.
Das einzige was mir hier etwas sagt ist die Feststellung: "wo Linux drauf steht kann durchaus inkompatibles drinstecken."

Nun, es ermöglicht Entwicklern - so die Zielvorstellung - die Pakete für RedHat und Co. erstellen, auf Knopfdruck gleich welche für Mageia mit zu erzeugen.

Dieses Wort in Gottes Ohr, wer veranlasst so einen Entwickler auch auf diesen "Knopf" zu drücken. Computer ist wie Religion und wenn du auf Leute triffst, die RH oder anderes für das "allein seeligmachende" halten, dann ist das wie der Blick mit dem Ofenrohr ins Gebirge.

Also dient das Projekt insgesamt dem Ziel. mehr Software unter Mageia verfügbar zu machen, ohne alles selber anpassen zu müssen.

Wer geht also mit zur Wallfahrt nach Andechs, beten und Kerze anzünden und wenn das trotzdem alles nichts nützt, dann hat man wenigstens ein paar Bergbock dunkel inhaliert.
Gruß
J.

[Alf1967]

Nun, es ermöglicht Entwicklern - so die Zielvorstellung - die Pakete für RedHat und Co. erstellen, auf Knopfdruck gleich welche für Mageia mit zu erzeugen.

Heißt das auch, wenn ich ein .rpm für RH/Fodora im Internet sehe, das es in den Quellen nicht gibt, das ich es demnächst als normaler Anwender auch einfach installieren kann? Da gibt es manchmal jaProbleme.

[unklar]

Ja, das kannst du.

[man-draker]

Ja, das kannst du.

Das wage ich zu bezweifeln.

Pakete die gezielt für Fedora/RedHat/CentOS erstellt wurden werden durch die Neuerungen nicht leichter installierbar sein, als bisher.
Es dann nur möglich, mit einem Knopfdruck / Befehl ein für Mageia bestimmtes Paket zu erzeugen, ohne sich über dessen Besonderheiten Gedanken machen zu müssen.

So jedenfalls schätze ich die durch die Neuerung zur Verfügung gestellte Möglichkeit ein. Und das halte ich für eine optimistische Sichtweise.

Schick wäre natürlich ein "Universalpaket", dass sich auf jeder unterstützten Distribution passend installiert. Das lese ich aber aus dem Text der Meldung nicht heraus.

[Feuervogel]

Ließe sich nicht alternativ der Open Build Service nutzen?

[unklar]

Das lese ich aber aus dem Text der Meldung nicht heraus.

Ich lese das schon so. Wobei ich zugebe, du kannst besser englisch!

[doktor5000]

Ließe sich nicht alternativ der Open Build Service nutzen?

Im Prinzip ist es genau das was beschrieben wurde, eine Alternative zum OBS. Auch im OBS bauen sich die Pakete "auf Knopfdruck" für alle augewählten Distros,
allerdings Anpassungen für unterschiedlichste Distributionen müssen nach wie vor vorgenommen werden.

Es dann nur möglich, mit einem Knopfdruck / Befehl ein für Mageia bestimmtes Paket zu erzeugen, ohne sich über dessen Besonderheiten Gedanken machen zu müssen.

Zu schreiben jeder könne dann per Knopfdruck Pakete für Mageia bauen ist zwar in der Theorie richtig, der zweite Teil ist in der Praxis aber weit an der Realität vorbei, und das steht auch nirgends in dem Blog - Wunschdenken.

[jkowalzik]

Schick wäre natürlich ein "Universalpaket", dass sich auf jeder unterstützten Distribution passend installiert. Das lese ich aber aus dem Text der Meldung nicht heraus.

Hallo!
Ein Schelm wer schlechtes dabei denkt: "warum müssen wir uns diese Frage eigentlich stellen?"
Linux entwickelt sich auseinander, das hat durchaus Vorteile, keiner kann irgendwelche Entwicklungen verhindern, aber und hier gestattet mir einen Vergleich. Unter dem Begriff "Hund" findet sich sowohl der Neufundländer als auch der Dackel, aber ein natürlicher Austausch ist unter den beiden nicht mehr möglich.
Die Überschrift enthält das Wort "dandify" = herausputzen von da ist es nicht mehr weit bis zum auskehren.
Also, entweder ist MGA konkurrenzfähig dann wird für MGA entwickelt, im anderen Fall eben nicht.
Gruß
J.

[psyca]

DNF sieht eher nach einer Alternative zu URPMI aus. Siehe auch den bereits übersetzten Wiki Eintrag https://wiki.mageia.org/de/Verwenden_von_DNF

[doktor5000]

Ja, so steht es ja auch im Blog, es bringt aber durch die Abstammung von Fedora eben auch die Integration vom yum-Repos mit sich, somit kann eben auch auf deren Seite die Unterstützung von Mageia erfolgen - ähnlich dem Opensuse Build Service, wie von Feuervogel beschrieben. Unterm Strich bringt es für den Endbenutzer erstmal nicht viele Veränderungen, außer dass die PackageKit-Integration vervollständigt wird, somit könnten Anwendungen die das unterstützen endlich Codecs installieren wenn diese benötigt werden z.B.

[Alf1967]

Pakete die gezielt für Fedora/RedHat/CentOS erstellt wurden werden durch die Neuerungen nicht leichter installierbar sein, als bisher.

Ich habe es mir gedacht.

[man-draker]

Zu schreiben jeder könne dann per Knopfdruck Pakete für Mageia bauen ist zwar in der Theorie richtig, der zweite Teil ist in der Praxis aber weit an der Realität vorbei, und das steht auch nirgends in dem Blog - Wunschdenken.

Wenn das reines Wunschdenken bleiben soll, wozu dann der enorme Aufwand?

[doktor5000]

dnf bringt noch ein paar andere Sachen unter der Decke mit, z.B. MirrorBrain-Unterstützung, was besseres, zuverlässigeres Management und automatische Auswahl der Spiegelserver unterstützt (da muss allerdings noch etwas in der Mageia-Infrastruktur getan werden, siehe z.B. https://bugs.mageia.org/show_bug.cgi?id=17400 ) und weil es eben auch die Unterstützung z.B. für Fedora-Paketbauer vereinfacht bzw. die Einstiegsschwelle absenkt, und das kann sehr positive Effekte haben.

Desweiteren hat sich urpmi in den letzten Jahren kaum weiterentwickelt, da es nur sehr wenige Perl-Entwickler bei uns gibt, die sich mit perl-urpm auskennen und man so recht einfach einen anderen erprobten Paketmanager nutzen kann, ohne selbst viel Wartungsaufwand reinzustecken. Auch die Unterstützung "weicher" bzw. dynamischer und binärer Abhängigkeiten welche in den aktuellen rpm.org-Versionen mitgekommen ist, kann so abgefackelt werden, mit urpmi ist das noch nicht möglich (bis auf Suggests bzw. Recommends wie sie seit einer Weile heißen). Siehe dazu u.a. https://en.opensuse.org/Libzypp/Dependencies und http://www.rpm.org/wiki/DynamicDependencies

[man-draker]

Wenn DNF à la longe urpm* ablösen soll, kann ich das nachvollziehen.
Unter dem Gesichtspunkt beschränkter Personalressourcen ein sinnvoller Ansatz.

[mbl103]

Zu schreiben jeder könne dann per Knopfdruck Pakete für Mageia bauen ist zwar in der Theorie richtig, der zweite Teil ist in der Praxis aber weit an der Realität vorbei, und das steht auch nirgends in dem Blog - Wunschdenken.

Genau so ist es. Der erwähnte Opensuse Build Service versucht sich dennoch an diesem Ansatz: Es wird ein Paket für Opensuse gebaut, dessen Steuerdatei einige Anpassungen an andere Distris enthält. Diese gehen aber selten über alternative Abhängigkeitsnamen oder distributionsspezifische Build-Makros hinaus. Dass aber andere Distributionen andere Paketbauregeln haben, bleibt weitestgehend unberücksichtigt. Wenn RPM am Ende ein Paket pro Zieldistribution ausspuckt, ist halt alles OK. Ob es Konflikte mit Installationspfaden anderer Pakete gibt, ob später eine saubere Aktualisierung möglich ist oder ob die gelegentlich etwas verzwickten "Requires" und "Provides" korrekt gesetzt sind, spielt erst einmal keine Rolle.

Daher denke ich, dass wir heute von einheitlichen, distributionsübergreifenden RPM-Paketen genau so weit entfernt sind wie vor mehr als zwei Jahrzehnten, als das Splitting begann und schon nach kurzer Zeit die RPM-Kompatibilität der verschiedenden Zweigdistris nicht mehr zu halten war. Aber dass die verwaiste urpmi-Entwicklung durch den Umstieg auf DNF aufgefangen werden soll, halte ich für einen Schritt in die richtige Richtung. Mehr Nutzer finden auch mehr Fehler – in der Hoffnung, dass sie diese auch melden. Aber keine Angst, DNF läuft bei mir auf Fedora 24 deutlich stabiler als damals Yum. Auch die Optionen beim Aufruf sind übersichtlicher geworden, denn vieles aus den früheren Yum-Plugins wurde direkt in DNF aufgenommen.

[jkowalzik]

Hallo!
Soll man dazu lachen oder weinen, wenn gesagt wird:

Wunschdenken.

Genau so ist es.

War denn URPMI nicht das Alleinstellungsmerkmal von M****A Fakt ist aber:

....dass die verwaiste urpmi-Entwicklung durch den Umstieg auf DNF aufgefangen werden soll, halte ich für einen Schritt in die richtige Richtung.

Ich sehe es jeden Tag hier in einem zur Mageia-Entwicklung konvergenten Bereich. Mittelständler sind irgendwann zu groß, als dass man auf sie verzichten könnte, aber zu klein um bestimmte Entwicklungen zu stemmen. Was tun? Es beginnt mit Kooperation und endet mit einer Übernahme.
Wie kann das aussehen
Ganz einfach, man nehme X und tausche den Startbildschirm aus.
Gruß
J.

[man-draker]

Aber dass die verwaiste urpmi-Entwicklung durch den Umstieg auf DNF aufgefangen werden soll, halte ich für einen Schritt in die richtige Richtung.

1. Woher die Erkenntnis, dass die Enwicklung verwaist ist?
2. Woher das Ziel, entgegen allen bisher getätigten Äußerungen?

[Alf1967]

1. Woher die Erkenntnis, dass die Enwicklung verwaist ist?

Ich kann jetzt nicht für mbl103 sprechen, aber daraus kann es schon rauslesen:

Desweiteren hat sich urpmi in den letzten Jahren kaum weiterentwickelt, da es nur sehr wenige Perl-Entwickler bei uns gibt, die sich mit perl-urpm auskennen ...

[Feuervogel]

Hallo zusammen,

zu DNF kann ich nichts schreiben, weil ich es schlichtweg noch nicht kenne. Meine Frage wäre, warum man sich nicht für libzypp, basierend auf PackageKit und damit das Kommandozeilenwerkzeug zypper entschieden hat?
Gerade als von openSUSE neben Mageia ist für mich das Alleinstellungsmerkmal dieser Distribution gegenüber anderen Linux-Distributionen eben YAST2 und zypper, zwei hervorragende Werkzeuge, die eben beide auf PackageKit aufbauen.

Wegen Novell, wegen SUSE/openSUSE?
Oder liegt es vor allem daran, dass Mageia traditionell eine gewisse Nähe zu Fedora/Red Hat hat?

Gruß
Feuervogel

[Bequimao]

Hi,

packagekit kann auch dnf. Dann gibt es Neal Gompa, einen Fedora-Entwickler, der die Arbeit für Mageia macht.

Grüße,
Bequimão

[doktor5000]

Meine Frage wäre, warum man sich nicht für libzypp, basierend auf PackageKit und damit das Kommandozeilenwerkzeug zypper entschieden hat?
Gerade als von openSUSE neben Mageia ist für mich das Alleinstellungsmerkmal dieser Distribution gegenüber anderen Linux-Distributionen eben YAST2 und zypper, zwei hervorragende Werkzeuge, die eben beide auf PackageKit aufbauen.

libzypp basiert nicht auf PackageKit, sondern auf der satsolver-Bibliothek: https://doc.opensuse.org/projects/libzypp/HEAD/index.html#thirdpfunc bzw. https://en.opensuse.org/openSUSE:Libzypp_satsolver
dnf benutzt die libsolv-Bibliothek, die aus satsolver resultiert, benutzt also unter der Decke was zypper auch benutzt. Auf zypper als Frontend zu wechseln ist aus technischen Gründen nicht so einfach möglich. Letztenendes können wir also mit dnf das benutzen, was zypper auch benutzt.

Und weder YAST noch zypper bauen auf PackageKit auf, PackageKit kann zypper/libzypp nutzen und nicht anders herum.

[mbl103]

1. Woher die Erkenntnis, dass die Enwicklung verwaist ist?

Ich kann jetzt nicht für mbl103 sprechen, aber daraus kann es schon rauslesen:

Desweiteren hat sich urpmi in den letzten Jahren kaum weiterentwickelt, da es nur sehr wenige Perl-Entwickler bei uns gibt, die sich mit perl-urpm auskennen ...

Genau darauf habe ich mit »verwaist« abgezielt. Für mich ist eine Software schon verwaist, wenn nur noch im Notbetrieb die ärgsten Bugs gefixt werden und sonst nichts mehr passiert. Das muss nicht heißen, dass das Projekt völlig tot ist, aber man kann eben nichts Neues mehr davon erwarten. Irgendwann verliert urpmi völlig den Anschluss an neue Technologien, da ist es nur verständlich, dass man heute schon nach Alternativen sucht.

… Meine Frage wäre, warum man sich nicht für libzypp, basierend auf PackageKit und damit das Kommandozeilenwerkzeug zypper entschieden hat?

Die Bibliothek libzypp hat ein PackageKit-Backend, nicht umgekehrt, das ist hier genau erklärt. Genau so funktioniert DNF auch: Man kann es im Terminal direkt benutzen, und für grafische Werkzeuge wie GNOME Software u.a. steht eine Anbindung an PackageKit bereit. PackageKit ist hier die Zwischenschicht zwischen Befehlszeilenwerkzeug und GUI-Programm.

Oder liegt es vor allem daran, dass Mageia traditionell eine gewisse Nähe zu Fedora/Red Hat hat?

Tief in den Paketen schleppt Mageia sicher heute noch Einiges an RedHat-Vermächtnissen mit sich herum. Aber die Nähe beschränkt sich wohl nur auf RPM selbst. Zumindest benutzt Mageia den RPM-Zweig 4.x und ist nicht wie OpenMandriva auf das inkompatible RPM 5.x umgeschwenkt.

Was ich aber noch zu bemerken hätte: Rpmdrake wird direkt von urpmi angetrieben und hat keine Anbindung an PackageKit. Damit steht im Mageia-Kontrollzentrum vorerst auch keine grafische Paketverwaltung auf DNF-Basis zur Verfügung. Sollte aber kein großes Problem sein, dann statt rpmdrake etwas anderes zu verwenden oder auch yumex-dnf, das direkt auf DNF aufsetzt und kein PackageKit braucht.

[mbl103]

War denn URPMI nicht das Alleinstellungsmerkmal von M****A

Eher nicht, das Alleinstellungsmerkmal war wohl das M****A-Kontrollzentrum. Ein Befehlszeilenwerkzeug wie urpmi taugt nicht als Benutzermagnet, wenn man insbesondere Einsteiger ansprechen will. Oder liege ich mit meiner Einschätzung der primären Mageia-Zielgruppe falsch?