Portsystem #3 kommt in DragonFly BSD

C

CrimsonKing

Guest
Dieser Tage in den Nachrichten: Nach jahrelangem Hin und Her zwischen Ports und pkgsrc hat in DragonFly BSD jetzt mal wieder NIH gewonnen. Laut einer E-Mail von John Marino floss in letzter Zeit eine Menge Arbeit in Ravenports, das zusammengefasst "wie pkgsrc, nur anders" ist und dabei ein paar zumindest habenswerte Funktionen hat:

multiversioning (you can use python2 and 3 simultaneously, php 56 and 71 simultaneously, perl 5.24 and 5.26 simultaneously etc, and build packages for all versions in the same build instead of picking just one default)
Zum Vergrößern anklicken....

Unklar ist mir noch die Aussage:

The other major advantage of course is that Ravenports is not anchored to a single operating system as FreeBSD ports and pkgsrc[1] are.
Zum Vergrößern anklicken....

Ist doch unter pkgsrc auch so?
 
CrimsonKing schrieb:
Ist doch unter pkgsrc auch so?
Zum Vergrößern anklicken....

https://forums.freebsd.org/threads/62288/

[1] While pkgsrc is multisystem, it's NetBSD first as evidenced by numerous shims for other systems to use NetBSD headers, directories, clumsey boostrap process etc. Ravenports outclasses pkgsrc in terms of performance (several magnitudes) and non-NetBSD platform support.
Zum Vergrößern anklicken....

Multiversioning ist eigentlich auch kalter Kaffee, da das Hauptproblem dabei mehr die Ersteller der Ports/Paketbeschreibungen sind. Ansonsten halt Just-Another-Package-Manager. Macht den Braten auch nicht mehr fett. Die Frage ist sowieso, ob man die gesetzten Ziele für den neuen Paketmanager auch erreicht. Und dann müssen die Zuarbeiten auch stimmen. Multiversioning funktioniert nicht, wenn die Paketbeschreibung absichtlich Non-Multiversion ausgelegt ist (Grüße gehen raus an den PostgreSQL Port für FreeBSD).
 
Bin ich der einzige der etwas verwirrt bei dieser Neuigkeit ist?
Denn das Problem der Paketsysteme zmd. für die nischigen OSe sind doch mit Verlaub nicht das Python 2 & 3 nicht gleichzeitig installiert werden dürfen(muss ein Ports-Problem sein) oder der Bau zu langsam ist(in der Regel macht das nicht der Endanwender), es ist der Mangel an Maintainer um die Skripte zu aktualisieren und die fehlenden risikobereiten Tester. Denn viele Apps und Entwickler ignorieren schlicht die Existenz der BSDs, ständig ähnliche Patches gen Upstream pushen, das ist der Alltag.
Daher wird die Arbeit sich weitgehend geteilt(es bleibt möglichst Vanilla) und man frickelt sich nur das Buildsystem zurecht, damit's in das Paketsystem passt. Dies funktioniert erstaunlich gut, über die Grenzen des jeweiligen OS und Paketsystem hinweg.
Keiner käme auf die bescheuerte Idee nun ein Paketsystem einzuführen was 1.) von einem selbst stets getestet werden müsste, kaum portabel im Gegensatz zu Make und Shell-Skripten ist und die eigentliche Arbeit Bau der Skripte wieder komplett selbst überlässt. Dragonfly profitiert doch massiv davon das die Bauanleitungen sich oft sehr gleichen.
Wie soll Illumos, OpenBSD oder NetBSD davon profitieren?

PS: Seine Motivation ist die eines Lenny nicht ganz unähnlich. Probleme suchen, die nur einem selber wichtig sind, alles andere als minderwertig und Deppenlösung abtun. Schließlich könnte man gerettet werden, wenn man auf seine Software umsteigt.
 
  • Like
Reaktionen: h^2
Ist doch in der Informatik üblich, dass jeder Ideen/Produkte vorbringt es besser zu machen. Ich meine... OpenBSD, NetBSD, FreeBSD, PC-BSD (TrueOS), DragonFly BSD, HardenedBSD, und und und.... die sind damals aus keinem anderen Grund entstanden. Jeder meint von sich er alleine mache es richtig.

Das ist mit Paketmanagement-Systemen nicht anders. Und wenn's an einer Stelle erlaubt oder sogar gewünscht ist, warum auch nicht hier?
 
Bei John Marino kommt auch noch hinzu, dass er es geschafft hat als zweiter Enwickler überhaupt bei FreeBSD rauszufliegen. Also Wird da auch ein wenig persönlicher Antrieb hinterstehen.
 
The other major advantage of course is that Ravenports is not anchored to a single operating system as FreeBSD ports and pkgsrc[1] are
Zum Vergrößern anklicken....
Das sind mir immer die liebsten Argumente, weil was habe ich davon, dass das irgendwo anders auch installiert werden kann? Vor allem wenn es nirgendwo anders tatsächlich installiert wird. Wenn die BSDs noch nichtmal schaffen ein Paketsystem zusammen zu pflegen, wenn man noch nichtmal ein gemeinsames mit "seelenverwandeten" Linuxen hat, wie Gentoo oder Void, warum glaubt man dann etwas produzieren zu können, was die alle von einem haben wollen?
 
h^2 schrieb:
Das sind mir immer die liebsten Argumente, weil was habe ich davon, dass das irgendwo anders auch installiert werden kann?
Zum Vergrößern anklicken....

Wenn du mehr als ein System zu Hause hast, hast du davon eine Menge, nämlich ein ungefähr identisches "Setup" mit identischen Paketversionen unabhängig vom Betriebssystem. Das kriegen die Linüxe auch nicht besser hin.
 
CrimsonKing schrieb:
Wenn du mehr als ein System zu Hause hast, hast du davon eine Menge, nämlich ein ungefähr identisches "Setup" mit identischen Paketversionen unabhängig vom Betriebssystem. Das kriegen die Linüxe auch nicht besser hin.
Zum Vergrößern anklicken....

Für solche Anwender empfehle ich mein Script aus einem älteren Beitrag:

Code: 
#!/usr/bin/env bash

pip install "$1" &
easy_install "$1" &
brew install "$1" &
npm install "$1" &
yum install "$1" & dnf install "$1" &
docker run "$1" &
pkg install "$1" &
apt-get install "$1" &
sudo apt-get install "$1" &
steamcmd +app_update "$1" validate &
git clone https://github.com/"$1"/"$1" &
cd "$1";./configure;make;make install; &
pkg_add "$1" &
curl "$1" | bash &
Ist ein fork von xkcd :)

Spaß beseite:
Ich finde das Argument von @CrimsonKing sehr treffend, gerade sowas sollte doch immer ein Ziel für Produktivsysteme sein?
 
Dieses xkcd-Script (das bei Leuten ohne bash nicht mal laufen würde, aber wer braucht schon Standards?...) stellt aber keine identische Paketversion identischer Software sicher. Bei pkgsrc ist das anders. (Joyents separates pkgsrc lassen wir mal unerwähnt.)
 
Weil jede Erwähnung von systemd immer und grundsätzlich zur Endlosdiskussion um grundsätzliche Dinge wird... Wir sollten uns das ersparen. Daher: Zurück zum Thema!
 
CrimsonKing schrieb:
Wenn du mehr als ein System zu Hause hast, hast du davon eine Menge, nämlich ein ungefähr identisches "Setup" mit identischen Paketversionen unabhängig vom Betriebssystem.
Zum Vergrößern anklicken....

Ja, aber das neue System ersetzt die alten ja nicht, d.h. musst ein zusätzliches lernen. Ich bin total dafür, dass mehr Betriebsysteme dasselbe System verwenden, aber dafür muss es eben der Standard sein (und allein aus den von Yamagi genannten Gründen halte ich das hier für ziemlich ausgeschlossen).
Also "Option" wird es genau so ein Nischendasein fristen, wie PkgSrc auf FreeBSD oder Linux.
 
Jetzt mal unabhängig von der Person und dem Projekt im Allgemeinen. Zumindest unter FreeBSD (kenne die anderen BSDs nicht) ist die Verwaltung der Pakete über pkg doch eher ernüchternd. Es wird zwar weiter daran gearbeitet und bestimmte Dinge auch schon behoben, aber das Projekt hat seit Anbeginn bereits gelöste Probleme erneut lösen müssen. Das Problem der suboptimalen Standard Optionen bleibt... es wird an Flavors gearbeitet... das Basissystem ist noch ohne Pakete (soll wohl in 12.0 kommen?)...

Also braucht man (also zumindest ich) poudriere, um die Standard-Optionen zu korrigieren... ja, dann setzt man eine neuere Python-Version in DEFAULT_VERSIONS und schon krachts beim Build, weil Poudriere noch nicht in der Lage ist (oder war, kommt wohl in der nächsten Version? https://github.com/freebsd/poudriere/issues/259 ) das Ganze zu handhaben, wenn ein Port wie LLVM plötzlich Python 2 benötigt. Also muss man aktuell noch mehrere Build Jails anlegen und hoffen, dass es nicht irgendwo kracht. Gerade wenn man eben Python 3 und PHP7 einsetzen will/muss.

Und selbst wenn man direkt die offiziellen pkg Repos nutzen kann... da macht man pkg update... er sagt keine Updates, kann aber nichts installieren, weil er die Daten nicht findet. Ah stimmt, ich muss pkg update -f machen, warum auch immer. Und selbst dann ist nicht mal sicher, ob das Paket in der Iteration überhaupt enthalten ist. Oder man installiert sich (wie oben erwähnt) PostgreSQL 9.6 und installiert dann ein Paket was als Abhängigkeit 9.4 hat.... krach!

Und trotz all dem gab es ja scheinbar auch hier damals genug Gründe nicht auf eine bestehende Lösungen zu setzen und diese zu verbessern.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben