Alternative Paketmanager unter FreeBSD

N

nert

BSD-Gutfinder
Moinsen.

Das Portssytem mit dem angeflanschten (ja, das ist durchaus eine Wertung ;)) Paketmanagement in allen Ehren aber ich frage mich und damit euch ob es nicht bereits Versuche gegeben hat ein alternatives Paketmanagement unter FreeBSD lauffaehig zu machen. Speziell faellt mir da pacman (http://www.archlinux.org/pacman/) ein welches mir aufgrund der relativen "Einfachheit" gut ins BSD-Konzept allgemein zu passen scheint.

Damit will ich nichts im Sinne von "Ey, werft den Kram weg und nehmt $FOO!" anregen sondern viel mehr fragen ob es bereits jemand versucht hat so ein System aufzusetzen, vllt. sogar mit funktionierendem Mirror. Falls nicht: waere das etwas was mal jemand ausprobieren wollen wuerde? Ja/nein/vielleicht/Gott nein/weiss nicht? Falls nicht: warum nicht? Falls mal ausprobiert: hat es getaugt? :)

Falls es einen Thread in dieser Art schon mal gab dann nur her mit dem Link, mich zurechtweisen und den Thread zumachen. :huth: Danke an alle.
 
Von der Beschreibung her eigentlich ziemlich genau wie FreeBSD mit aufgeflanschten Tools. Nur das die Tools gleich mitgeliefert sind.

Im Grunde genommen ist es doch so, du hast ein Backend (Ports) oder Tinderbox/Pointyhead und für ein Frontend (portmaster, portupgrade, kports, ...) musst du dich selbst entscheiden. Der Unterschied bei pacman ist, dass Backend und Frontend zusammen kommen.

Eigentlich gefällt es mir ganz gut die Auswahl zu haben. Frontends zu Tinderbox/Pointyhead sind allerdings Mangelware. Kports und portupgrade sind hier als Zwitter Möglichkeiten, mein pkg_upgrade wird aber meines Wissens nach die erste Tinderbox/Pointyhead only Lösung sein.

Dann steht einem ja noch PkgSrc zur Verfügung, wahrscheinlich besonders geeignet für diejenigen, die mehrere BSDs einsetzen.

Man kann natürlich ein beliebiges Paketsystem verwenden, aber irgndwer muss ja die Datenbank pflegen, also einfach mal ausprobieren ist das schlicht nicht drin.
 
Kamikaze schrieb:
Von der Beschreibung her eigentlich ziemlich genau wie FreeBSD mit aufgeflanschten Tools. Nur das die Tools gleich mitgeliefert sind.
Zum Vergrößern anklicken....

Das ist natuerlich ein zugkraeftiges Argument. Will man wirklich ein third-party-tool in ein Betriebssystem integrieren? Das kann ohne entsprechendes Hintergrundwissen schoen nach hinten losgehen...

Kamikaze schrieb:
Im Grunde genommen ist es doch so, du hast ein Backend (Ports) oder Tinderbox/Pointyhead und für ein Frontend (portmaster, portupgrade, kports, ...) musst du dich selbst entscheiden. Der Unterschied bei pacman ist, dass Backend und Frontend zusammen kommen.
Zum Vergrößern anklicken....

Ich denke dass Problem ist eigentlich gar nicht die Technik. Denn wie du weiter unten ja beschrieben hattest ist das Problem eher die Pflege der Datenbanken als die bereitgestellten Tools. Da liegt fuer mich, ganz subjektiv, des Pudels Kern.

Kamikaze schrieb:
Eigentlich gefällt es mir ganz gut die Auswahl zu haben. Frontends zu Tinderbox/Pointyhead sind allerdings Mangelware. Kports und portupgrade sind hier als Zwitter Möglichkeiten, mein pkg_upgrade wird aber meines Wissens nach die erste Tinderbox/Pointyhead only Lösung sein.
Zum Vergrößern anklicken....

Da kommen wir doch im Endeffekt zum Kern der Sache selbst: es ist ja nicht so, dass ich mich wirklich fuer ein Backend entscheiden kann. Selbst wenn ich nur sicherheitsrelevante Fixes haben will muss ich Ports oder die stable Pakete verwenden. Bei den Ports ist man auf der sicheren Seite: die sind fast immer aktuell etc. Aber wie wir alle wissen sind die Stable-Pakete nicht notwendigerweise vollstaendig und ich muss stellenweise auf Ports zurueckgreifen. Also muss man einen Mix fahren aus Ports und Paketen, selbst wenn man eigentlich keine Version-Whore ist. Das stoesst mir leicht auf. Aber nur leicht. :)

Es ist also total egal welches Paketmanagement man faehrt. Denn mit Ports und Paketen ist man eigentlich gut versorgt mit aktueller Software. Aber "leicht" ist es deswegen noch nicht. :)
 
Die Paketauswahl ist schon ziemlich gigantisch. Im Moment gibt es für 7-stable 18236 Pakete. De fehlt zu den 20000 Ports gar nicht so viel.

Ich vermute mal da gibt es für Debian mehr, aber sonst kann da wohl kaum ein Linux mithalten. Und so aktuell wie die Debian-Pakete sind die FreeBSD-Pakete doch allemal.
 
Bei distrowatch habe ich letzte Woche erst in dem PC-BSD Artikel gelesen, dass Debian ca 13.000 Pakete hat, wenn man die ganzen -dev Pakete abzieht.
 
Fuer mich ist das Portssystem einer der wichtigsten Gruende warum ich FreeBSD so gerne benutze. Auch wenn es immer ein Layer 8-Problem gewesen sein mag, hatte ich mit allen anderen Systemen die ich im laufe der Jahre benutzt habe immer mehr Probleme.
 
Das ist eine philosophische Frage. Ports sind ziemlich dumme Scripte, die dem Nutzer nur helfen sollen, die Sachen zu bauen. Sie erheben gar nicht den Anspruch, irgendwelcher Intelligenz und müssen sie auch gar nicht. Denn das ist nicht ihr Sinn. Auf der anderen Seite ist es nun aber so, dass man im Jahre 2009 etwa das fünfzigfache an Paketen installiert hat als damals im schönen Jahr 1996, als die Ports neu waren. Mit völlig manueller Systemadministration in Sachen Paketen ist es daher heute ziemlich auswändig bis eklig, weshalb man in all den Jahren immer neue Aufsätze auf die Ports geschrieben hat. Einige semioffiziell, andere komplett inoffiziell. Diese Tool, egal ob Portupgrade, Portmaster oder ganz was anderes sind aber jetztendlich nur Wrapper um die dummen Ports. Was sich ab und an rächt. Portupgrade versucht durch seine Datenbanken eine gewisse Intelligenz hineinzubekommen und ist meiner persönlichen Meinung nach von all diesen Tools auch noch immer das mit sehr großen Abstand beste und zuverlässigste. Portmaster akzeptiert das die Ports dumm sind und reicht diese Dummheit an den Nutzer durch, was auch seine Vorteile hat. Aber wie dem auch sei, keines dieser Tools macht magisch aus den Ports ein Apt. Um ein System wir Apt zu realisieren, müsste man erst ganz unten Veränderungen vornehmen. Aber will man das überhaupt? Man würde schließlich auch die nicht gerade kleinen Nachteile dieser hochautomatisierten Systeme bekommen und man hätte die Arbeit, die zusätzlich benötigten Daten in den Ports bereitzustellen. Eine Frage, die nicht so leicht zu beantworten ist.

Aber, um zu dem Thema zurückzukommen, Die meisten Linux-Systeme kann man nicht problemlos übernehmen. Das Linux in entscheidenden Punkten gänzlich anders funktioniert. Das von den meisten Distributionen genutzte SysV-Init, für viele Dinge /proc statt systcl, der "alles ist ein Paket" Ansatz... Man konnte zeitweilig Apt über die Debian-Base im Linuxulator laufen lassen, aber wirklich Spaß machte das nie. Was also klar sein muss ist, dass es viel, sehr viel Aufwand wäre. Pacman wäre, auch aufgrund der kaum zu leugnenden ideologischen Verwandtschaft von Archlinux mit FreeBSD, sicher noch am geeignetsten und am ehesten machbar. Auch, das Pacman mit libarchiv auf einem für FreeBSD entwickeltem Framework aufsetzt.
 
In meinen Augen sind es auch gerade die dummen, einfachen Skripte, die dafür sorgen, dass die Software-Basis in den Ports so unglaublich umfassend ist - eben weil es nicht so fürchterlich aufwändig ist einen Port zu erstellen. Der Aufwand für ein .deb-Paket ist ungleich höher (Pacman hält sich dagegen schon in Grenzen).

Wieviel Automagie ein Port mitbringt, hängt im wesentlichen allein von der Entscheidung des Maintainers ab - es gibt ports, die neben dem dumpfen kompilieren und installieren auch noch einige Setup-Arbeit leisten (User anlegen, etc) - theoretisch wäre auch eine interaktive Konfiguration à la aptitude denkbar (auch wenn das sicherlich keinen großen Spaß macht, so etwas zu implementieren - da wäre viel Handarbeit angesagt...)
 
@Yamagi
Dein Lob an portupgrade kann ich nicht nachvollziehen. Immer wieder kam es bei mir damit zu kaputten Abhängigkeiten, sogar zyklischen! Die sollte man dann mit pkgdb -F fixen, das mit willdem Herumgelösche von Abhängigkeiten alles noch schlimmer gemacht hat.
 
Kamikaze schrieb:
Dein Lob an portupgrade kann ich nicht nachvollziehen. Immer wieder kam es bei mir damit zu kaputten Abhängigkeiten, sogar zyklischen! Die sollte man dann mit pkgdb -F fixen, das mit willdem Herumgelösche von Abhängigkeiten alles noch schlimmer gemacht hat.
Zum Vergrößern anklicken....

Das ist leider auch meine erfahrung mit portupgrade, wenn man nicht immer alles zeitnahe updatet.

Schade nur das es kein tool gibt, welches Offiziell unterstützt wird, und im Basissystem vorhanden ist. O.k. man könnte sagen es gibt ja 'make install clean', was bei mehreren hundert upzudatenen Ports ja bekanntlich wenig spass macht.

Gut finde ich, das in der /usr/ports/UPDATING häufig optionen für portupgrade und portmaster drinstehten.

Aber ein tool wie portmaster was 'nativ' gepflegt wird, würde ich als Vorteil empfinden.

jm2c
 
Na wie man hier lesen kann ist in der Welt der Pakages eben doch nicht alles in Ordnung. Dachte schon, dass es nur mir so geht. :-)

Dass ein "Draufgeflansche" von z.B. pacman keine Loesung sein kann ist m.E. nach diskutabel. Aber das kommt nur darauf an, was man genau moechte. Mir persoenlich wuerde es schon reichen wenn, so wie rolle es schon beschreibt, es einen offiziell anerkannten Weg gibt, Binaerpakete effizient zu aktualisieren ohne auf Drittpakete zurueckgreifen zu muessen. Denn die sind, wenn man es genau betrachtet, auch nur angeflanscht und bei Problemen haften halt die Nutzer. Und kann das denn im Sinne des Betriebssystems selbst sein? Yamagi sagt es ja bereits sehr schoen: unter Umstaenden reicht einem bei der Menge der Pakete das vorhandene System nicht mehr aus. Ich kann mir durchaus Situationen vorstellen bei denen man damit absolut zufrieden ist aber auch eben genug Situationen in denen das nicht mehr so ist.
 
portmaster funktioniert für mich super, da muss ich äußerst selten manuell eingreifen (vor allem im Vergleich zu portupgrade. Ich denke die Situation ist wirklich nicht sooo übel.

Was die Binärpakete angeht. Du kannst jederzeit alle löschen und mit pkg_add -r wieder aufspielen. Das ist die zuverlässigste Methode. Mein Skript ist da auch bloß eine Abkürzung, die nie so zuverlässig sein wird.
 
Meine Erfahrung mit Portupgrade ist dahingehend, dass es mit hochkomplexen Updates wie dem leidigen X.org oder auch den halbjährlichen GTK-Updates sehr gut klarkommt, besser als jedes andere Tool. Anwerfen, laufen lassen, fertig. Gut, früher gab es einmal ab und an Probleme mit der Datenbank, die sind aber seit spätesten 2.4.0 gelöst. Ich habe schon seit Ewigkeiten kein pkgdb(1) mehr anwerfen müssen. Und selbst wenn, dass sind vielleicht 2 Minuten. Und wenn es die Abhängigkeiten total zerschießt, kann man die Datenbank schlicht neu aufbauen oder im Extremfall die Abhängigkeiten selbst gegen den Portstree wiederaufnehmen lassen.

Meine Erfahrungen mit Portmaster gehen in genau die gegenteilige Richtung. Sehr gut, solange es einfache Updates sind. Aber wehe es sind viele Updates oder komplizierte. Was ich da an Fehler beobachtet habe, war ganz und gar unschön. Baut die Ports in der falschen Reihenfolge neu, läuft schnell in Zyklen wie a -> b -> c -> a und schmiert ab und an mal ab. Gerade letztes hat sehr viel Ärger gemacht, da war die Paketdatenbank im Eimer und auch durch manuellen Eingriff praktisch nicht mehr zu retten.

Naja, jetztendlich muss jeder selbst wissen, was das beste für ihn ist und vermutlich macht auch jeder andere Erfahrungen. :)
 
Yamagi schrieb:
Aber wie dem auch sei, keines dieser Tools macht magisch aus den Ports ein Apt. Um ein System wir Apt zu realisieren, müsste man erst ganz unten Veränderungen vornehmen. Aber will man das überhaupt? Man würde schließlich auch die nicht gerade kleinen Nachteile dieser hochautomatisierten Systeme bekommen und man hätte die Arbeit, die zusätzlich benötigten Daten in den Ports bereitzustellen. Eine Frage, die nicht so leicht zu beantworten ist.
Zum Vergrößern anklicken....

Eins muss man apt lassen: Es ist um den Faktor 100 schneller als pkg_*. Ein apt-get dist-upgrade mit vielen neu zu installierenden Paketen ist manchmal schneller als ein einfaches pkg_add -r foo.
Ich weiss nicht, wo es da bei pkg_add hakt, aber bis das erstmal ans Laufen kommt, dauert es teilweiweise viele Sekunden, da hat apt schon längst alle Pakete parallel heruntergeladen. Ausserdem scheint es bei Apt eine gescheite Lastverteilung über die einzelnen Server zu geben, bei pkg_add wird immer nur genau ein Server genommen, während bei es bei den apt Servern ein Loadbalancing gibt, sodass man immer sauschnelle Server bekommt.
 
Unterstützung für simultane Downloads, auf mehrere Server verteilt. Gute Idee, das kann ich dann direkt in die nächste Version einbauen.
 
laemodost schrieb:
Eins muss man apt lassen: Es ist um den Faktor 100 schneller als pkg_*. Ein apt-get dist-upgrade mit vielen neu zu installierenden Paketen ist manchmal schneller als ein einfaches pkg_add -r foo.
Ich weiss nicht, wo es da bei pkg_add hakt, aber bis das erstmal ans Laufen kommt, dauert es teilweiweise viele Sekunden, da hat apt schon längst alle Pakete parallel heruntergeladen. ....
Zum Vergrößern anklicken....
Das kann pkg_upgrade im Entwicklungszweig jetzt auch. :)

Eine super Methode sich den Zorn seiner Mitbewohner zuzuziehen, die sich gar nicht darüber freuen, dass man so viel Traffic erzeugt ...:huth:
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben