Warum arbeiten nicht alle an Pkgsrc?

menhir

Member
Seid gegrüßt,

Wieso nutzen nicht alle BSDs das pkgsrc Paketformat?

Ich meine, wir haben ein portables Paketformat, wie es in der Szene der freien Software nicht ein
zweites Mal gibt. Es bietet nicht nur eine wirklich grosse Anzahl an Paketen, sondern
kann auch von vielen Paketen Varianten bilden - ähnlich wie die Linuxer es von Gentoo her kennen -.

Mir ist schon bewusst, dass NetBSD (logischerweise ;-) ) und auch DragonFly schon pkgsrc nutzen,
aber die beiden doch bekannteren Free und Open lassen es leider beiseite.

Wenn alle mal an einem Strang ziehen würden, dann hätte man nicht nur noch mehr Augen, die die
Probleme erkennen, und somit die Qualität erhöhen - ihr wisst ja, was mit diesem Argument gemeint ist -,
nein, man könnte auch etwas bieten, was die GNU/Linux Welt in ihrer zerstrittenen Art
nicht zustande bringt. Stellt euch einfach mal ein Repository vor aus dem RedHat, Debian und Gentoo
gebildet/gebaut/usw. wird - ich kürze die Argumente hier etwas ab, weil ich denke, ihr könnt
euch vorstellen, was ich meine -. Was würde die GNU/Linux Welt damit schon allein marketingtechnisch
reissen. Von den Möglichkeiten, die sich dann auftun, durch hunderttausend Augen, die auf ein
Repo blicken, will ich gar nicht reden. (Und nebenbei, ich denke, wenigstens den Leuten hier ist
klar, dass das technisch sehr wohl machbar wäre.)

Nun, wenn die GNU/Linux Welt nicht will, warum dann nicht die BSD Welt?

Viele setzen - bestimmt auch aus dieser Community - BSDs in kommerziellen Settings ein. Klar,
warum auch nicht? Es gibt so ein "vereinheitlichtes" Paketformat schon, was wohl dem einen oder anderen
Admin, was sagen sollte: Openpkg. Ist so ähnlich wie Pkgsrc. Nur, da steckt auch etwas Geschäft
dahinter(,was ja auch vollkommen in Ordnung ist).
Nur sehe ich nicht, dass die BSD Community(ies) hinter Openpkg stehen, ABER wir haben eben so etwas
wie Openpkg schon.

Also, warum wird nicht ein Free Software App Shop (so etwas ähnliches wie die IPhone/Android App Shops)
gebaut, indem die Ports Entwickler ihren Hirnschmalz auch hinter Pkgsrc stecken, und
nicht nur die Pakete (also die "Bau Rezepte") schreiben, sondern auch dann die Binären Pakete
bauen? Man würde gemeinsam an den Optimierungen arbeiten. Man würde gemeinsam an allen
Varianten für verschiedene Einsatzzwecke arbeiten.
Ach, man würde eben einfach _die_ Vielfalt erschaffen, aber eben aus einem "Samenkorn".

Ausserdem, fällt mir gerade so ein, während ich das hier schreibe: Viele Repositories schreien
nach neuen Entwicklern, weil es an vielen Stellen eben bei jedem der grossen Repos nicht genug
Entwickler gibt. Durch diese Konzentration könnte man dieses Problem wenigstens minimieren.
Dann auch die "Ausbildung" von den Paket-Entwicklern, wäre natürlich stark vereinfacht.


Ich sehe nur Vorteile (für die BSDs auf jeden Fall, aber auch für die GNU/Linux Welt, wenn sie denn
über ihren Schatten springen kann), wenn man sich auf Pkgsrc konzentriert.


(Ja, da gibt es eine kleine Sache: Statt Pkgsrc könnte man ja auch Dpkg oder auch die
OpenBSD Ports nehmen und für alle Betriebssysteme die Thrid-Party Programme bauen. ABER bei Pkgsrc,
weil es eben aus der NetBSD Kultur stammt, ist der portable Betrieb schon eingebaut, ich wüsste
wirklich nicht wie ich Dpkg auf OpenBSD und OpenBSDs Ports auf Ubuntu zum laufen bekomme.
Pkgsrc "funktioniert" einfach. Es ist nur auf einigen Basis-Systemen nicht richtig getestet und
unterstützt, das ist alles.)



Ich bin mal wirklich auf eure Antworten und Gedanken gespannt
und hoffe, dass wir hier mal eine Diskussion starten, wie man
so ein Free Software App Shop auf Pkgsrc angehen könnte als Community.

euer
Menhir
 
Ich stimme dir zu!

Nicht nur DragonFly und NetBSD nutzen pkgsrc standardmäßig sondern auch ein paar kleinere Linuxdistributionen:
http://www.dracolinux.org/
http://voltalinux.sicurezzarete.com/
http://linux.nethence.com/

Desweiteren sei erwähnt, dass pkgsrc auf diversen Plattformen auch real genutzt wird ist auch schon länger bekannt:
http://www.bsdnewsletter.com/2006/10/Features174.html

Warum arbeiten nun nicht alle an pkgsrc?
  • Manche mögen keine Portsysteme: Dafür gibt es aber jetzt pkgin
  • Viele meinen ihres sei besser: allerdings sind sie häufig nicht sehr portabel/zu optimiert
  • Wenige Pakte: wobei es in den meisten fällen mit einem url2pkg getan ist
  • pkgsrc hat keinen Hype und ist fast nur in der (Net)BSD-Welt bekannt

Was man dagegen machen kann?
  • Werbung: Es gibt Logos und man kann drüber reden. Das bringt neue User und vor allem Entwickler
  • Distributionen: pkgsrc+Solaris, pkgsrc+Darwin, pkgsrc+OpenBSD, pkgsrc+FreeBSD und was sonst noch so möglich ist - vor allem lizenztechnisch. Ansonsten vielleicht Installer statt dem Bootstrap. Wäre auch sicher Cool pkgsrc für Windows zu haben-
  • Interfaces: Sowas wie pkgin, zum Beispiel etwas das man statt Gentoos emerge verwendbar ist. So kompatibel wie möglich, damit es auch keine Scripts zerstört
  • Mehr Pakete: Vieles ist von jedem Leuten schaffbar, der ein BSD verwenden kann. Man braucht meist keine Programmierkentnisse. Mit pkgsrc-wip[2] gibt es einen Sandkasten für jeden
  • pkgsrc selbst verbessern: pkgsrc ist sicher nicht perfekt und so gut wie jede Software kann verbessert werden. Auch die Pakete selbst kann man verbessern.
  • Die Idee eines gemeinsamen, portablen Paket-/Portsystems vermitteln

Vor allem zum letzten Punkt könnte man ja eine endlos lange Liste anführen. Es gibt sicherlich hunderte von Vorteilen eines einheitlichen Paketsystems. Viele Pakete, Vorteile für Autoren von Paketen, die gleich Portabilität testen können, viele Anleitungen, viele extrafeatures (wegen der Manpower), weil es genug Manpower gibt, immer up2date weil Software genau dafür gemacht wird und gleich nach dem Release von Software das Paket geupdated werden kann, etc.

Und jede Menge andere Vorteile von viele User, viele Entwickler, Standards, etc.

Aber da wäre ein Rewrite vielleicht am Besten.

[1] http://imil.net/pkgin/
[2] http://pkgsrc-wip.sourceforge.net/
 
Zuletzt bearbeitet:
Kamikaze: Das war aber nicht die Frage. FreeBSDs Portsystem ist nicht portabel. Nichtmal DragonFly, welches ein direkter Abkömmling von FreeBSD ist kann sie verwenden. Anfangs wollte man ja..

Wenn dem so wäre, würden die Linuxdistributionen und Unices die FreeBSD Ports verwenden und nicht pkgsrc.

Außerdem ist das auch kein Grund für irgendwas anderes. Wäre ja toll, wenn man immer das verwendet hätte, was zuerst da war. Dann würden wir jetzt noch <veralteten Dreck hier einsetzen> verwenden. Abakus statt Computer oder sehr groteske Programmiersprachen zum Beispiel.
 
Zuletzt bearbeitet:
@Athaba: Statt über die FreeBSDler herzufallen, wäre es angemessener, ihnen zu erklären, welchen Nutzen sie denn davon hätten, auf pkgsrc zu migrieren. Immerhin sind es die FreeBSD Ports, die momentan die mit über 20k Ports größte Sammlung darstellen. FreeBSD hat auch die größte Userbase. Und dass die Ports in anderen Systemen nicht nutzbar sind, ist weder ein Problem der FreeBSD-Entwickler noch der Ports ansich; die benötigten Tools (haupts. FreeBSDs Make) sind quelloffen für jedermann verfügbar.

Für mich stellt sich das erst mal so dar: die (von der Userbase her) kleineren BSDs würden davon profitieren, wenn FreeBSD auf pkgsrc umstellen würde, weil sie dann automatisch von der riesigen Ports-Sammlung von FreeBSD profitieren würden. Aber welchen Nutzen hätte FreeBSD davon, diesen riesigen Aufwand in Kauf zu nehmen? Und bitte nicht wieder mit <veralteter Dreck> kommen; die Ports sind das gewiss nicht. Ich sehe in pkgsrc keinen Fortschritt gegenüber den FreeBSD Ports, sondern nur eine andere Implementierung desselben Lösungswegs.
 
Ich kann da nur aus reiner Nutzerperspektive meinen Senf zu geben. Insofern wäre mein Hauptkritikpunkt, dass pkgsrc (ganau so wie die FreeBSD-Ports) im Alltagsbetrieb einfach zu umständlich und zu zeitaufwändig sind.

Wenn ich ein System aufsetze, möchte ich nicht jede Anwendung einzeln kompilieren und mich im Zweifelsfall noch tagelang durch Foren wühlen, wenn der Vorgang nach ein paar Stunden abbricht. Das mag ok sein, wenn man Experte/Entwickler ist - für mich als reinen Anwender sind die Kompilier-Orgien einfach nur nervig.

Ich habe jetzt bei den xBSD die "big three" Free-, Net- und OpenBSD ausprobiert sowie eine Reihe Linux-Distributionen (inkl. ihrer verschiedenen Paketmanagement-Ansätze). Früher oder später komme ich aber immer wieder auf Debian und APT bzw. Aptitude als Frontend zurück. Wie gesagt - das gilt für meine Ansprüche!

Das Ports-System bzw. pkgsrc mag ja toll sein, wenn man die Anwendungen sehr individuell für eine ganz bestimmte Umgebung mit ganz bestimmten Ansprüchen anpassen muss/will. Dann wäre auch das umständliche, langwierige Kompilieren zu akzeptieren oder auch dass es öfter mal vorkommt, dass der Prozess abbricht.

Aber wenn die Anforderung lautet: Ich möchte mir jetzt schnell einen Desktop mit Browser, Textverarbeitung und ein paar Multimediaapplikationen installieren, dann ist es - zumindest aus meiner Perspektive - wenig Nutzerfreundlich, wenn dieser Vorgang ein ganzes Wochenende in Anspruch nimmt.
 
Okay Leute,

es hat unglaubliche 3 Posts gedauert, bis wieder einmal die Streitigkeiten
losgingen.

Eigentlich würde ich gerade von den Communities der freien Software
mehr Geimeinschatfssinn erwarten. Doch irgendwie kann man diese Leute,
nicht an einen Tisch holen. Immer gibt es diese - entschuldigt - Gott verfluchten
Zwistigkeiten. Ports waren zuerst da.
Weisst du was, du Noob, die CBT Tapes waren schon da und wurden bespielt, als deine tollen BSD Hacker noch flüssig waren. Capiche?

An die Mods hier: Bitte schliesst diesen Thread ab, wenn ihr dies hier zu lesen bekommt. Ich entschuldige mich, dass ich diesen Thread eröffnet habe.


Tschau!
 
Okay Leute,

es hat unglaubliche 3 Posts gedauert, bis wieder einmal die Streitigkeiten
losgingen.

Eigentlich würde ich gerade von den Communities der freien Software
mehr Geimeinschatfssinn erwarten. Doch irgendwie kann man diese Leute,
nicht an einen Tisch holen. Immer gibt es diese - entschuldigt - Gott verfluchten
Zwistigkeiten. Ports waren zuerst da.
Weisst du was, du Noob, die CBT Tapes waren schon da und wurden bespielt, als deine tollen BSD Hacker noch flüssig waren. Capiche?

An die Mods hier: Bitte schliesst diesen Thread ab, wenn ihr dies hier zu lesen bekommt. Ich entschuldige mich, dass ich diesen Thread eröffnet habe.


Tschau!

Ooops, so schnell beleidigte Leberwurst:eek:?

Nix für ungut, aber wenn Du in einem öffentlichen Forum erwartest, das nur Deine Meinung bestätigt wird, kann ich nur sagen "Welcome to reality!":D

<klugscheiss>Diskussionen haben übrigens die Eigenheit, dass sie u. a. über den Austausch kontroverser Meinungen für alle Beteiligten mehr Klarheit schaffen können (rpt. können!)</klugscheiss>
 
Ach, du wolltest das alle deine Weltneuheit-Idee super finden und "hurra" schreien?! Sag das doch bitte beim nächsten mal vorher, sonst kommt hier noch tatsächlich ein Gespräch mit mehreren Meinungen zu Stande... :p

Im Ernst jetzt mal: Ich finde nicht das das hier un konstruktive Streitigkeiten sind. Alles ganz ruhig. Also reg dich einfach nicht auf und diskutiere mit!

entspannte Grüße!
 
Okay Leute,

es hat unglaubliche 3 Posts gedauert, bis wieder einmal die Streitigkeiten
losgingen.

Eigentlich ja jetzt nicht wirklich. Ich bin auch nicht der Meinung, dass man direkt zu machen muss.

Ich überlege schon seit einiger Zeit mal eine ausführliche Übersicht über BSD-Paketsysteme zu schreiben. Zu dem Thema habe ich mir auch viele Gedanken gemacht.

Ergebnis:
Theoretisch wäre es für alle BSDs besser ein Paketsystem zu nutzen.
Praktisch halte ich es (leider) für absolut unrealistisch, weil sich mindestens zwei der Systeme jetzt auf eine "Fusion" einigen müssten und dahin sofort viel Man-Power umlenken. Kurzfristig würde sich das negativ auf alle Beteiligten auswirken.
Dann gibt es noch die ideologischen Probleme, die schwer sein werden zu überwinden:
1. von welchen Paketsystem startet man aus? Es spricht da durch aus einiges für jeden und gegen jeden Kandidaten
2. Release-Zyklen-Frage: Rolling-Release(FreeBSD), Quartale (PkgSrc), Release-Zweige(OpenBSD)
3. Authorität -> wer fällt in Zukunft welche Entscheidungen?
4. Ego: jeder findet seins am Besten und wird sicher weigern Abstriche zu machen, auch wenns unwichtig
...
 
Die Frage war, "Wieso nutzen nicht alle BSDs das pkgsrc Paketformat?".

Meine Antwort beantwortet diese Frage für FreeBSD. Da FreeBSD Teilmenge von alle ist ohne alle zu sein, beantwortet es die Frage sogar vollständig.
 
Ich kann da nur aus reiner Nutzerperspektive meinen Senf zu geben. Insofern wäre mein Hauptkritikpunkt, dass pkgsrc (ganau so wie die FreeBSD-Ports) im Alltagsbetrieb einfach zu umständlich und zu zeitaufwändig sind.

Wenn ich den OP richtig verstehe, will er ja u.a. auch, dass Binaries zur Verfuegung gestellt werden, damit man nicht jeden Furz selbst bauen muss.

Ich habe jetzt bei den xBSD die "big three" Free-, Net- und OpenBSD ausprobiert sowie eine Reihe Linux-Distributionen (inkl. ihrer verschiedenen Paketmanagement-Ansätze). Früher oder später komme ich aber immer wieder auf Debian und APT bzw. Aptitude als Frontend zurück. Wie gesagt - das gilt für meine Ansprüche!

Soweit ich weiss, gibt es auch fuer FreeBSD fertig gebaute Pakete. Fuer OpenBSD sowieso, da iwird sogar *empfohlen*, fuer den normalen Betrieb Pakete zu nehmen. Wo ist jetzt Dein Problem, speziell mit OpenBSD?

Aber wenn die Anforderung lautet: Ich möchte mir jetzt schnell einen Desktop mit Browser, Textverarbeitung und ein paar Multimediaapplikationen installieren, dann ist es - zumindest aus meiner Perspektive - wenig Nutzerfreundlich, wenn dieser Vorgang ein ganzes Wochenende in Anspruch nimmt.

Unter OpenBSD reicht idR sowas:

$ sudo pkg_add -i mozilla-firefox kdebase openoffice mplayer

Wie das unter FreeBSD geht (und ob NetBSD vielleicht auch fertig aus pkgsrc gebautes Zeugs anbietet), weiss ich nicht, dazu kann ja vielleicht jemand anderes etwas schreiben.
 
(Disclaimer: als OpenBSD-Entwickler kann ich hier weitgehend nur zu OpenBSD was schreiben, bei den anderen BSDs kann ich nur spekulieren)

Wieso nutzen nicht alle BSDs das pkgsrc Paketformat?

Mal abgesehen von der Frage, was nun besser ist (FreeBSD-Ports (und Packages?), OpenBSD-Ports und Packages, pkgsrc):

Wie stellst Du DIr eine Migration (von FreeBSD und OpenBSD) vor? Da muesste sich erstmal jemand hinsetzen und pkgsrc soweit anpassen, dass mindestens alles, was z.Z. unter FreeBSD und OpenBSD laeuft, auch mit pkgsrc funktioniert.

Dann gibt es das Problem, dass die Systeme unterschiedliche Ziele verfolgen. Bei OpenBSD ist es z.B. definitives Ziel, fertig compilierte Packages zur Verfuegung zu stellen, jeweils passend zur aktuellen Release, und, nachdem william@ vor ein paar Wochen dazugesstossen ist, eventuell auch wieder fuer -stable (zumindest gibt's inzwischen wieder Commits im stable Portstree, ob es auch wieder Packages fuer mindestens i386 und amd64 geben wird, weiss ich noch nicht).

FreeBSD hat mit Abstand die meisten Ports, und wenn ich das richtig verstehe, gibt's da zwar auch binary Pakete, aber die meisten bauen trotzdem selber (warum auch immer, ich kann das wirklich nicht beurteilen).

Weiteres Prolblem: Test- und Releasezyklen. Zumindest bei OpenBSD gibt es zweimal im Jahr einen Lock, waehrend dem nur noch in extremen Ausnahmefaellen etwas committed werden darf (uebrigens wurde der Tree gerade heute gelocked), weil dann Packages fuer die naechste Release gebaut werden. Ob es so etwas bei den anderen BSDs gibt, weiss ich nicht, aber wenn, dann haette man das Problem, dass eigentlich immer irgendein System gerade im Lock-Zustand ist und niemand mehr committen kann. Und identische Releasezyklen bei den BSDs wird es mit Sicherheit niemals geben.

Dann: Qualitaetsmanagement: ich denke, es gibt da durchaus unterschiedliche Ansprueche. Bei OpenBSD muss vor allem die Installation und auch das Update von Binaerpaketen so einwandfrei wie moeglich klappen, wir legen deshalb z.B. auch extremen Wert darauf, dass die Abhaengigkeiten und die Packinglists wirklich stimmen. Ich weiss nicht, wie das bei FreeBSD und NetBSD gehandhabt wird, bei OpenBSD gibt's aber definitiv Pruegel, wenn man beim Update eines Ports nicht sicherstellt, dass pkg_add(8) auch wirklich merkt, dass das aus dem Port gebaute Binary neu ist und daher bei einem pkg_add -ui aktualisiert werden muss. Andererseits ist uns bei OpenBSD zwar nicht schnuppe, wenn sich ein Port nicht bauen laesst, weil eine aeltere Version davon bereits installiert ist (z.B. cups oder webkit), aber wir stecken da auch keine grosse Arbeit rein, weil die Packages sowieso auf frisch installierten Maschinen gebaut werden. Bei FreeBSD duerfte das anders sein, eben weil da so viele Leute lieber selbst bauen und es bestimmt nicht lustig faenden, wenn sie, um cups neu zu bauen, cups (und alles, was davon abhaengt) erstmal deinstallieren muessten.

Und was ist, wenn die Leute mal nicht einer Meinung sind? Was ist, wenn jemand einen Port fuer "sein" BSD aktualisiert, der Port dann aber bei den anderen BSDs nicht mehr funktioniert? Wie willst Du *das* jemals koordinieren?
 
Ja steinex, ist es. Das ändert aber nichts daran, daß ich es nicht wagen würde jemandem zu empfehlen, sich bei der Systemintegration auf Binarys zu verlassen. Deshalb der Hinweis auf diesen Umstand.
 
Die stable-Pakete werden von den Pointyhead Servern halt so schnell es geht den Ports automatisch hinterhergebaut. Das ganze ist den Ports in der Regel einige Wochen hinterher. Einfach eine Frage der Kapazität.
 
Ich frage mich, ob das überhaupt möglich ist, ein PKGSRC für alle 4 BSDs. Schließlich haben alle BSDs Eigenheiten(Bibliotheken, Kernelfeature). Auch muss man viele Kompromisse eingehen hinsichtlich Qualität, Aktualität etc..
 
Bitte lass dich/lasst euch von den ersten Antworten nicht in die irre führen. Ich habe weiter unten erst bemerkt, dass das ganze wahrscheinlich auf Basis ein blöden Aussage von mir beruht.

@Athaba: Statt über die FreeBSDler herzufallen,
Wo falle ich über die FreeBSDler her?

Ich habe lediglich gesagt, dass FreeBSD Ports nicht portabel genug sind um für andere Systeme (ohne Modifikation) brauchbar zu sein.

Einfach das zu nehmen, was zu erst da war halte ich für eine nicht sehr sinnvolle Regel.

wäre es angemessener, ihnen zu erklären, welchen Nutzen sie denn davon hätten, auf pkgsrc zu migrieren.
Die Vorteile habe ich (und auch der Threadersteller) angeschnitten. Sie sind denen von Standards ähnlich. Außerdem wird den Meisten klar sein, dass vereinte Kräfte Vorteile bringen. Mal abgesehen davon habe ich deinen Vorschlag vorhin schon erwähnt:

Die Idee eines gemeinsamen, portablen Paket-/Portsystems vermitteln

Immerhin sind es die FreeBSD Ports, die momentan die mit über 20k Ports größte Sammlung darstellen.

Ich habe ebenfalls geschrieben, dass pkgsrc mehr Pakete braucht:

FreeBSD hat auch die größte Userbase.
Erstens habe ich das nicht bestritten und zweitens hätte ein einheitliches Portsystem mehr Nutzer. Außerdem weiß ich nicht, was das mit dem Thema zu tun hat.

Und dass die Ports in anderen Systemen nicht nutzbar sind, ist weder ein Problem der FreeBSD-Entwickler noch der Ports ansich; die benötigten Tools (haupts. FreeBSDs Make) sind quelloffen für jedermann verfügbar.
Das mit dem offenen Code habe ich nicht bestritten, dass es ihr Problem ist auch nicht, aber das heißt trotzdem nicht, dass es portabel ist. Das Portsystem ist für FreeBSD gemacht und derzeit _nur_ dafür und deshalb nicht für alle nutzbar. pkgsrc ist portabel, siehe Website und Nutzer (mein erster Post). Siehst du das als Beleidigung?

Für mich stellt sich das erst mal so dar: die (von der Userbase her) kleineren BSDs würden davon profitieren, wenn FreeBSD auf pkgsrc umstellen würde,
Ja ein einheitliches Paketsystem/pkgsrc würde von einer größeren Userbase profitieren. Das habe ich auch geschrieben (wenn auch undeutsch :ugly: - habe wohl was abgeschnitten, sorry):
Und jede Menge andere Vorteile von viele User, viele Entwickler, Standards, etc.

Stört dich das oder um was geht es dir?

weil sie dann automatisch von der riesigen Ports-Sammlung von FreeBSD profitieren würden.
Was meinst du damit?
Wenn man sie einfach kopieren könnte hätte man das schon gemacht, aber so einfach ist das nicht.

Aber welchen Nutzen hätte FreeBSD davon, diesen riesigen Aufwand in Kauf zu nehmen?
Ein einheitliches Portssystem bringt mehr Nutzer, mehr Entwickler, mehr Ports, mehr Support von Softwareanbietern.

Und bitte nicht wieder mit <veralteter Dreck> kommen; die Ports sind das gewiss nicht. Ich sehe in pkgsrc keinen Fortschritt gegenüber den FreeBSD Ports, sondern nur eine andere Implementierung desselben Lösungswegs.
Ouch! Hat dich das so irritiert? Dann war es ein Missverständnis. Damit waren NICHT die Ports gemeint. Es ging _ausschließlich_ um das Argument "weil es zuerst da war". Tut mir leid, wenn ich das schlecht geschrieben hat.

Es ging darum, dass die Argumentation "es war zuerst da" Schwachsinn ist. Ich weiß nicht, ob die lange Erklärung Kamikaze sagte "Kurze Antwort" besser ist. Aber mit Kamikaze streite ich ja gerne. Ich glaube bei einer Flashdiskussion haben wir uns mal zusammengerauft. Das waren Zeiten... :D

Ich habe nichts gegen FreeBSD Ports und auch nichts gegen FreeBSD. Warum sollte ich? Hier geht es auch gar nicht darum was besser ist. Ich dachte, dass hätte ich klar gemacht, als ich schrieb, dass ein Rewrite das Beste ist.

Es geht darum, dass pkgsrc auf ziemlichvielen Platformen zumindest über 50% der Pakte baut. Meines Wissens (und bessert mich aus, wenn das nicht stimmt!) ging es den FreeBSD-Leuten nie darum die Ports portabel zu machen. Sie wollten lediglich, dass sie auf FreeBSD so gut wie möglich funktionieren. Zum einen hat das den Vorteile, dass die Manpower in das hinzufügen und Pflegen neuer Ports gesteckt werden kann und zum Anderen kann man die Ports dann voll auf FreeBSD optimieren und die meisten Betriebssysteme, Linudistributionen und BSDs wollen genanu das: Eine Plattform, auf der sie für ihre User das Beste bieten können. Was auch noch zu erwähnen ist, ist dass die "Wahl" das System nicht auf Portabilität auszulegen realistisch gesehen sogar intelligenter war. Neben den oben genannten Vorteilen, seht euch openpkg und pkgsrc einmal an: Sie fristen ein Schattendasein, obwohl beide Projekte dafür ausgelegt sind überall zu laufen. Ich halte es nicht für sehr realistisch die Linuxwelt zu erobern (gegen RPM und apt-get anzukommen) und auch, dass sich die BSDs zusammenraufen halte ich nicht für realistisch.

Bei einem portablen System für alle gibt es Vorteile. Wie gesagt fände ich es intelligenter, wenn man denn die Kräfte vereinen will was komplett neues zu machen. Schon um die Altlasten loszuwerden und alles basierend auf modernen Tools/Bibliotheken zu machen. Man könnte sicherlich ein auch etwas machen um die Arbeit der Projekte (OpenBSDs ports, FreeBSDs ports und pkgsrc) einzuarbeiten. Ich denke die Ideen von cpan6 könnten ein guter Ausgangspunkt oder sogar selbst der Packagemanager sein.

Aber nochmals an alle, die sich gekränkt fühlen: Es ging darum, dass pkgsrc portabeler ist. Versucht mal das FreeBSD Ports auf AIX, IRIX, Linux, ... zum laufen zu bekommen. Vielleicht wäre es sinnvoll daran zu arbeiten das die FreeBSD Ports portabler sind, vielleicht wäre ein Merge aller Portsysteme das Beste, vielleicht ein Rewrite. Ich bin auch nicht der Meinung, dass irgendeines dieser Projekte die Aufgabe hat das ganze zu tun, die Leitung zu übernehmen und ich bin auch nicht der Meinung, dass FreeBSDs Ports schlecht sind, weil sie nicht portabel sind. Es gibt mehr Ports, mehr User, etc. und um ganz ehrlich zu sein es gibt etwas, was mich an den FreeBSD Ports stört: Sie sind, wenn auch mehr deutlich veralteter, als die von pkgsrc[1], doch das habe ich schon mal wo geschrieben und ich, weiß, dass ich sie updaten soll und das habe ich bei den von mir verwendeten Ports auch gemacht. Aber das ist nicht das Thema und ich bin deshalb kein Feind oder sowas von FreeBSD oder dem Portsystem. Ich schreib das nur, um meine Position zu den FreeBSD Ports klar zu machen und zu zeigen, wie ich ehrlich über die Sache denke. Wahrscheinlich wäre ich nicht mal BSD-Fan, wenn ich nicht FreeBSD als erstes getestet hätte. Es war das erste OS, das mich wirklich überzeugt hat.

Sorry, das war jetzt OT, aber ich will nicht bei einem Thema wo es um Zusammenarbeit geht mit Streits anfangen. Vor allem nicht, wenn sie auf einem Missverständnis beruhen, das auf meinem Mist gewachsen ist. Bei der Bezeichnung <veralteter Dreck> ging es um Kamikazes "weil es zuerst da war" und wie ich Kamikaze kenne war das eine Zusammenfassung von einem besseren Argument, die ich mit meinem zweiten in diesem Thread geschriebenen Posting aus ihm herausquetschen wollte. Da wäre wohl eine PM besser gewesen, aber vielleicht hat es ja was gutes, wenn ich meine Position so einmal klar mache. Wenn ihr mir sie nicht abkauft, dann schreibt das und ich halte mich aus der weiteren Diskussion raus und denke über das, was ich geschrieben habe nach. Flamwars (und ich meine die persönliche Sorte und nicht was, wo etwas produktives dabei rauskommt) anzetteln ist das letzte, was ich will.


[1] Das ich übrigens auch nicht als so toll empfinde, weil es im Gegenteil zu den FreeBSD Ports, häufig Probleme mit den Upgrade von Pakten macht. Das sehe ich übrigens als ein sehr großes Problem und deshalb hatte ich gehofft, dass sich die Idee eines DragonFly-Entwicklers auf pacman (erfunden von Arch und ebenfalls von Frugalware Linux verwendet) umzusteigen Anklang findet.

Gruß,
Athaba, der fälschlicherweise immer davon ausgeht, dass das was er schreibt auch von anderen so verstanden wird, wie er es gemeint hat und daran arbeiten sollte

EDIT:
Ich frage mich, ob das überhaupt möglich ist, ein PKGSRC für alle 4 BSDs. Schließlich haben alle BSDs Eigenheiten(Bibliotheken, Kernelfeature). Auch muss man viele Kompromisse eingehen hinsichtlich Qualität, Aktualität etc..
Das ist ja die Herausforderung. pkgsrc läuft grundsätzlich nicht allzu schlecht auf allen BSDs, aber sicherlich nicht überall Perfekt. Nur denke ich, dass wenn alle BSDs ein Paketsystem nutzen würden die Manpower das kompensieren würde. Auch darf man nicht vergessen, dass es wahrscheinlich eine verbesserte Schnittstelle zwischen dem Paketsystem, den Autoren von Software und den Bibliotheken der BSDs entstehen würde. Eigentlich versuchen ja alle sich ein wenig an POSIX und auch an Linux zu halten, damit man sich Arbeit erspart. Hast du dir schonmal so ein Paket genauer angesehen? In den Meisten gibt es nicht viele Anpassungen. Vieles machen ./configure und Co., wie auch immer man zu diesen Tools stehen mag.

EDIT2: Weil es scheint, als wäre das für die meisten nicht klar:
pkgsrc ist nicht so viel anders, wie die ports (und packages) von OpenBSD und FreeBSD. Der einzige Unterschied ist, dass man schon immer daran gearbeitet hat, dass das Zeug (pkgsrc und die einzelnen Pakete) auch unter anderen Betriebssystemen funktionieren. Ja, auch unter OpenBSD und FreeBSD. Ansonsten wäre es wohl am sinnvollsten das Größte, als FreeBSDs Portssystem zu nehmen.


Portabilität ist der einzige Grund, der für pkgsrc spricht, aber auch der ausschlaggebendste, wenn man bedenkt, dass es eben die o.g. Linux-Distributionen pkgsrc gewählt haben. Es wäre schlicht und ergreifend zu viel Arbeit gewesen, wenn sie die Ports von FreeBSD oder OpenBSD genommen hätten. Da muss man eben abwiegen, wie man beginnen will:
viele Ports, hohe Portabilität oder gleich was ganz neues, mit noch unimplementierten Konzepten, die die Arbeit erleichtern und viele neue Features bringen. Ich weiß nicht was am besten ist... vor allem, wenn man damit rechnet, dass mehrere Projekte zusammenarbeiten.
 
Zuletzt bearbeitet:
Ich habe lediglich gesagt, dass FreeBSD Ports nicht portabel genug sind um für andere Systeme (ohne Modifikation) brauchbar zu sein.
Richtig, das liegt aber nicht am Ports-System selbst, sondern an dessen Inhalt. Ob ein spezielller Port auch auf einem anderen BSD kompiliert, ist mehr eine Sache des Inhalts der Makefiles als der Ports-Systematik ansich. Ich glaube daher, dass auch ein anderes Meta-System wie pkgsrc dieses Dilemma nicht würde lösen können. Dazu müsste man schon etwas hoch automagisches kreieren, ähnlich CMake.

Einfach das zu nehmen, was zu erst da war halte ich für eine nicht sehr sinnvolle Regel.
ACK, aber Du wirst mir sicher ebenfalls zustimmen, dass es schon eine sehr große, saftige Möhre sein muss, die man jemandem vor die Nase hängt, bevor er die Ressourcen reinsteckt, um eine solche Migration in Angriff zu nehmen.

Die Vorteile habe ich (und auch der Threadersteller) angeschnitten. Sie sind denen von Standards ähnlich. Außerdem wird den Meisten klar sein, dass vereinte Kräfte Vorteile bringen.
Und da liegt der Hase im Pfeffer. Ich behaupte mal, dass pkgsrc aus technischer Sicht den Open- und FreeBSD-Ports nicht überlegen ist (es gibt aber auch hybride Systeme wie das von ArchLinux eingesetzte Pacman, die es IMO durchaus sind). Und was die Vorteile von Standards anbelangt: Was glaubst Du, warum Microsoft so wahnsinnig an ODF interessiert war? Auch wenn ich hierfür Trollprügel beziehen werde, die Situation ist IMHO in etwa vergleichbar.

Ich habe ebenfalls geschrieben, dass pkgsrc mehr Pakete braucht:
Ja, nur wer soll die bereit stellen? Port-Maintainer und -Commiter sind in allen BSD-Projekten nicht gerate im Überfluss vorhanden. Und Tatsache ist, dass die Projekte, die heute pkgsrc nutzen, hier den kleinsten Beitrag leisten könnten.

und zweitens hätte ein einheitliches Portsystem mehr Nutzer. Außerdem weiß ich nicht, was das mit dem Thema zu tun hat.
Der Nutzer-Zuwachs wäre aus FreeBSD-Sicht nicht so furchtbar groß.

Das mit dem offenen Code habe ich nicht bestritten, dass es ihr Problem ist auch nicht, aber das heißt trotzdem nicht, dass es portabel ist. Das Portsystem ist für FreeBSD gemacht und derzeit _nur_ dafür und deshalb nicht für alle nutzbar. pkgsrc ist portabel, siehe Website und Nutzer (mein erster Post).
Siehe meine Erläuterung oben - jedes Meta-Paketsystem ist genau so portabel wie die dafür geschriebenen Ports. Das würde sich auch durch den Einsatz eines anderen Meta-Paketsystems nicht ändern.

Um das mal an einem Beispiel zu verdeutlichen: Im FreeBSD Ports Tree finden sich derzeit knapp 25.000 Patches, die dafür sorgen, dass sich Software überhaupt kompilieren oder installieren lässt bzw. in die FreeBSD-Dateisystemhierarchie passt. Du kannst stark davon ausgehen, dass diese Patches auch benötigt würden, wenn die Software von einem anderen Meta-System verteilt würde.

Neben den bereits von Kili angesprochenen Schwierigkeiten (unterschiedliche Release-Zyklen, unterschiedliche Philosophie beim Umgang mit Drittanbieter-Software) käme also noch hinzu, dass in einem wie auch immer gearteten übergreifenden Meta-Paketsystem systemspezifische Patches für jedes bediente System gepflegt werden müssten.

Siehst du das als Beleidigung?
Wie kommst Du darauf?

Stört dich das oder um was geht es dir?
Meine Frage ist immer noch nicht beantwortet: Warum sollte Open- oder FreeBSD den gewaltigen Kraftakt auf sich nehmen, um ein Meta-Paketsystem durch ein anderes zu ersetzen?

Ein einheitliches Portssystem bringt mehr Nutzer, mehr Entwickler, mehr Ports, mehr Support von Softwareanbietern.
Ich glaube, das überschätzt Du etwas. >90% der Ports in pkgsrc dürften sich auch in den FreeBSD Ports wiederfinden. Ein Merge würde wohl eine Handvoll Entwickler mehr zusammenbringen, die aber auf Jahre hinaus mit der Migration beschäftigt wären.

Wenn wirklich ein signifikanter Zuwachs und vor allem mehr Gewichtet gegenüber Software-Anbietern angestrebt werden soll (wobei ich darin im Moment noch keinen direkten Nutzen sehe, anders als z. B. bei Treiber-Unterstützung*), dann müsste mindestens eine große Linux-Distribution (am besten eine mit kommerziellem Hintergrund) oder Apple mit Mac OS X mit auf den Zug aufspringen.

* Unterstützung durch Software-Hersteller: Wenn es um Closed Source Software geht, ist eher die nicht gegebene Binärkompatibilität zwischen den diversen Unices das Hauptproblem. Das ist aber eine Angelegenheit der Kernel-Entwickler und nicht des Paketverwaltungssystems. Bei Open Source Software ist die Existenz von Ports mehr eine Frage der Manpower.

Grundsätzlich und in der Theorie ist es natürlich eine schöne Sache, wenn alle Port-Entwickler einen systemübergreifenden Ports Tree (oder wie das Ding auch immer heißen mag) pflegen. In der Praxis wird es aber weiterhin Entwickler geben, die für jeweils eines der Systeme anpassen, testen und freigeben. Außer den vorprogrammierten Konflikten wäre damit nicht so furchtbar viel gewonnen.
 
Wie sieht überhaupt die Qualitätssicherung bei pkgsrc aus? Wenn ich als Maintainer einen Port x für System y aktualisiere kann ich ihn ja i.d.R. auch nur auf System y testen. Wie wird sichergestellt, dass die neue Version erfolgreich auf Systemen a, b und c baut?

Es klingt zwar schön, ein einheitliches Format zu haben, aber meiner Meinung nach werden die Maintainer immer primär darauf achten, dass ein Port auf einem vom Maintainer selbst benutzten System baut.
 
Zurück
Oben