Login
Newsletter
Werbung

Thema: Debian stellt auf RPM um

4 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
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.

Pro-Linux
Unterstützer werden
Neue Nachrichten
Werbung