Warum arbeiten nicht alle an Pkgsrc?

[nihonto]

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 hab' ihn eher so verstanden, dass er pkgsrc als beste Erfindung seit geschnittenem Schwarzbrot ansieht und sich fragt, warum nicht alle ausschließlich darauf setzen.

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?

Da gibt's kein Problem. Aber hier im Thread ging es um pkgsrc und nicht um zusätzlich zur Verfügung gestellte binary-packages.

Grade weil OpenBSD nicht auf Ports oder pkgsrc setzt, benutze ich es ja.

Bei Free- und NetBSD hab' ich aber immer den Eindruck gehabt, die fertigen Pakete sind eher so ein Nebenbei-Produkt, das ganz klar nicht im Zentrum des Interesses steht.

Aber auf diesen Aspekt bin ich in meinem ersten Posting bewusst nicht eingegangen, da der OP nach pkgsrc gefragt hat und nicht nach Workarounds für Leute, die Ports/pkgsrc nicht mögen.

 

[lme]

Bei Free- und NetBSD hab' ich aber immer den Eindruck gehabt, die fertigen Pakete sind eher so ein Nebenbei-Produkt, das ganz klar nicht im Zentrum das Interesses steht.

Bei FreeBSD ist das definitiv so. Das Hauptaugenmerk liegt auf der Stabilität des Ports-Systems, die zum Download angebotenen Pakete sind die Ergebnisse der Test-Builds.
Durch die Parallelisierung der Builds (make -jx) und die Spende von neuer Hardware (okay ist jetzt auch nicht mehr soooo neu...) sind die Pakete inzwischen aber wesentlich aktueller als "früher".

 

[Athaba]

Zur Qualitätssicherung/Portabilität unter pkgsrc der Lebensweg eines Paketes:

Neue, unstabile und Testpakete hat man zuerst einmal in pkgsrc-wip, welches selbst kein Teil vom eigentlichen pkgsrc ist, aber trotzdem viel genutzt wird - Leute stoßen vor allem durch pkgsrc.se darauf. Die Qualität von pkgsrc-wip ist logischerweise niedriger, aber auch nicht unter aller Sau. Sie sind durchaus verwendbar und werden auch verwendet. Dort tummeln sich auch Leute, die erst Erfahrung sammeln und man bekommt einfach commit-access. Es gibt eigentlich keine Qualitätssicherung, auch wenn einige pkgsrc-Entwickler ein Auge drauf werfen. Ist ein Paket gut genug (hat DESTDIR-support, keine Fehler mit pkglint und läuft auf mehr als eine Plattform/einem OS) wird es nach pkgsrc importiert.

pkgsrc-head/current wird von den Meisten verwendet. Die Pakte (>90% - schwankt, weil wenn ein Paket von dem viele andere Pakete abhängig sind ausfällt kann das große Auswirkungen haben) dort funktionieren zumindest unter DragonFly (release+current), NetBSD i386/x86-64/ppc eben den üblicheren Plattformen und meist auch auf nicht ganz so alltäglichen - je nach Paket.

Dann gibt es noch die freezes in jedem Quartal. Hier geht es _nur_ um Qualitätssicherung. Es sind ausschließlich bug fixes und Securityupdates in den daraus resultierenden Branches. Diese Branches haben extrem viele Bulkbuilds (alle Pakete werden gebaut und Binärpakete werden erstellt). Das sind die Pakete, die meist (manchmal sind es auch welches aus Current) über pkg_add von den Servern zugänglich sind. Für alle OpenBSDler: Das ist sowas ähnliches, wie das was auf den CDs ist. Die FreeBSDler haben ja ebenfalls Freezes, aber ich weiß nicht wie das da genau abläuft.

Die Ergebnisse dieser Builds werden an eine Mailingliste[1] gesendet und die Maintainer können nachsehen, ob alles gebaut wird.



Um's nochmal zu sagen: Ich behaupte nicht, dass die Qualität unter pkgsrc besser ist - dazu habe ich von beiden viel zu wenig Ahnung. Es ist nur so, dass meines Wissens bis jetzt niemand die FreeBSD Ports abseits von FreeBSD erfolgreich verwendet hat. Ich weiß nur, dass die Leute vom DragonFly-Projekt das ursprünglich wollten, aber auf Grund mangelnder Portabilität nicht geklappt hat.

Ich finde auch nicht, dass FreeBSD das hätte tun sollen und es FreeBSD wahrscheinlich sogar geschadet hätte, weil das ja eine zusätzliche Arbeit wäre und die Chancen für ein einheitliches Paketsystem ohnehin nicht sehr gut stehen.

Ich habe zu wenig Erfahrung um zu sagen, was mehr Arbeit wäre: Neues System, FreeBSD Ports als Basis eines Paketsystems für alle oder NetBSD als Paketsystems für alle.

Ich weiß nur, dass wenn man derzeit als einzelne Person die Wahl hat auf einem Linux oder Solaris ein pkgsrc oder FreeBSD Ports (oder OpenBSD Ports) zu installieren mit pkgsrc um längen besser fährt, weil es da Leute gibt, die wollen und daran arbeiten, dass es unter Linux/Solaris läuft. Kurzum bin ich nicht der Einzige, der so etwas benutzt.

Das soll alles kein System schlecht dastehen lassen. Die Vorteile von FreeBSD Ports kennt ja jeder: Mehr Pakte, mehr User, mehr Entwickler, besser an FreeBSD selbst angepasst, miwi, besseres Upgrade als pkgsrc.

So und jetzt die Vorteile eines einheitlichen Systems egal was für eines (pkgsrc, FBSD ports, OBSD ports, Gentoos portage, pacman, openpkg, was neues, ...)

Mehr Entwickler:
Je nach Anzahl der Leute/Projekte, die mitmachen
Das bedeutet:
mehr Maintainer: Leute die nach dem rechten sehen, die sorgen, dass es abseits von x86 läuft, mehr Optimierungen mehr Idee/Features, mehr miwis

mehr Entwickler, die das System kennen/nutzen: Direkter Support von den Entwicklern, die Entwickler tun sich einfacher das System portabel zu halten (weil es mehr Bulkbuilds auf mehr Plattformen gibt), bessere Software- und Paketqualität

mehr User: mehr Support, es wird einfacher jemanden etwas zu zeigen, auch wenn dieser Jemand ein anderes OS nutzt. Die Entwickler wissen können leichter erfahren, wer die Software nutzt, wen es sowieso nur eine Bezugsquelle gibt und man eventuell einen popularity-contest macht, umso mehr User es gibt, umso wahrscheinlicher ist, dass sich die offizielle Dokumentation auf die Installation mit einem bestimmten Paketmanager geht.

Man müsste aber wirklich alle dazu bewegen: also nicht nur die BSDs, auch Linuxleute, Solaris, etc.

Das ist so, wie bei Standards: Wenn nur ein Browser sie unterstützt macht es keinen Sinn, wenn nur ein OS sich an POSIX hält macht das keinen Sinn, wenn nur ein Programm XML, gzip, PAM unterstützt macht es keinen Sinn

Vielleicht wäre ein einheitlicher Portstandard besser und alle sharen die Ports, aber damit würden viele Vorteile verloren gehen und es wäre gleich viel arbeit. Also vielleicht lieber ein Projekt starten, das einen Standard entwirft, den dann implementiert, dann werden Converter gebaut mit dem bestehende Pakete umgewandelt werden können.

Oder man sucht generell einen guten Ausgangspunkt, wie cpan6[2], hilft damit und baut dazu einen Converter.

oder man vergisst/ignoriert die Idee der Zusammenarbeit einfach und kocht weiterhin sein eigenes Süppchen.

[1] http://mail-index.netbsd.org/pkgsrc-bulk/tindex.html
[2] http://cpan6.org/

 

[mawei]

Wieso nutzen nicht alle BSDs das pkgsrc Paketformat?

Puh, schwere Frage!! Warum gibt es überhaupt soviele BSDs - warum arbeiten nicht alle an NetBSD? ;-)

Offensichtlich ist entweder die Not nicht groß genug oder pkgsrc trotz Portabilität nicht attraktiv genug. Portabilität ist ja auch nicht alles.

Portable Build-Systeme gibt es übrigens nicht nur in der BSD-Welt.

Als komplexes System ist pkgsrc schwer überschaubar, noch immer nicht vollständig dokumentiert und vom Handling her kompliziert. Von daher ist es für neue Maintainer nicht besonders attraktiv.

Wobei ich mich erneut frage, welches der vielen Build-System denn das am einfachsten zu erlernende und zu handhabende ist? Und bei welchem wird die Software möglichst "pur" also "Upstream-nah" gebaut, das heißt möglichst ohne Patches? Da sind für mich neben der Portabilität die wichtigen Kriterien.

Für den reinen Anwender ist es erst recht nicht gut geeignet, kaputt ist da ja immer was - klar bei einem System das sich permanent verändert. Brauchbares Paketmanagement bietet pkgsrc ja nicht. Funktionales und benuzterfreundliches Paketmanagement wird zwar derzeit implementiert, aber das hat halt mit dem eigentlichen "Framework zum Bauen von Anwendungsprogrammen" (also pkgsrc!) nicht viel zu tun. Wie und womit die Pakete gebaut werden ist für den reinen BSD-Anwender völlig egal.

Weiterentwicklung findet bei pkgsrc zwar permanent statt, aber herauragende Innovationen oder Visionen gab und gibt es nicht. Und wenn doch, dann wurde nichts draus. Sogar das Ziel der Cross-Kompilierbarkeit wird nicht mehr wirklich weiterverfolgt.

Na ja, ist kein Drama. Schade ist aber generell, dass da bei pkgsrc, den FreeBSD-Ports und all den anderen ähnlichen Systemen so viele gute und kompetente Leute dran arbeiten müssen, um die Systeme aufrechtzuerhalten. Ich halte das für verschwendete Ressourcen.

Für mich ist daher eher die Frage, wann man das mühevolle und permanent notwendige Pflegen endlich sein lässt und die Arbeit an diesen Systemen einstellt.

Sinnvoll fände ich nur ein Meta-Buildsystem, das nicht nur die Sourcen sondern dazu auch gleich die von den Entwicklern benutzten Build-Systeme "abholt" und installiert. Dann arbeitet man genau mit der Infrastruktur, die die jeweiligen Entwickler einsetzen. Nachteil: 100 bis 1000 unterschiedliche Build-System auf der Platte! Aber was soll's, zumindest Speicherplatz den haben wir ja.


Ciao, Mark

 

[mawei]

Auch die meisten anderen Systeme zur Bereitstellung von Software-Packeten würde ich gerne sterben sehen. Und ersetzt durch Lösungen, die die Packete direkt von den Entwicklern beziehen.

Die Packet-Maitainer haben alle was drauf und ich habe Respekt vor deren Arbeit und Leistung. Aber das mit der Qualität der Pakete funtkioniert halt letztlich nicht. Nur drei Beispiele aktueller Linux-Systeme wo es viel genutzte Standard-Anwendungen betrifft:

* Debian - kaputtes OpenOffice Writer

* Mandriva - kaputtes XSane

* Ubuntu - keine funktionierende Rechtschreibung in OpenOffice Writer und nicht funktionierende Netzwerkdrucker-Konfiguration (smb)

Ich habe in den letzten Woche die aktuellen Releases von Debian, Ubuntu, Fedora, OpenSUSE und Mandriva getestet. Irgendeine Standardsoftware ist immer fehlkonfiguriert oder kaputt :-(

 

[Athaba]

Waruben sterben lassen?

Gerade bei BSD hast du ja ein Standardsystem und kannst von da aus auf ports/pkgsrc verzichten und die Software selber bauen bzw. Binaries installieren. Windowslike Installer gibt es ja auch für Unix, falls du selbst einen Installer für ein Projekt bauen willst.

Bei den Linuxdistributionen ist es ja manchmal schwieriger, weil das Basissystem auch in Paketen steckt. Trotzdem gibt oft etwas, wie ein Standardsystem bzw. wäre es nicht schwer selbst eines zu kreieren. Sekeleton für das Dateisystem, Kernel, Coreutils, GCC und noch ein paar Kleinigkeiten. Am Besten ein kleines Script machen, dass dir ein Image baut oder alternativ so etwas, wie Buildroot oder Linux from Scratch verwenden und du hast dein Basissystem und kannst dir dein System selber zusammenbauen. Allerdings würde ich da ein paar RSS-Feeds verfolgen, damit du weißt wenn was neues rauskommt.

Slackware ist auch ein guter Ausgangspunkt.

 

[Daemotron]

Sinnvoll fände ich nur ein Meta-Buildsystem, das nicht nur die Sourcen sondern dazu auch gleich die von den Entwicklern benutzten Build-Systeme "abholt" und installiert. Dann arbeitet man genau mit der Infrastruktur, die die jeweiligen Entwickler einsetzen. Nachteil: 100 bis 1000 unterschiedliche Build-System auf der Platte! Aber was soll's, zumindest Speicherplatz den haben wir ja.

Nur um der technical correctness willen eine kleine Richtigstellung: Ports & Co ersetzen nicht die von den Entwicklern verwendeten Build-Systeme, sondern bilden ein Frontend zu eben jenen. GNU autoconf, cmake & Co. wird auch bei den heutigen Port-Systemen zwingend benötigt, wenn die originären Entwickler einer Software diese Build-Systeme in ihren Source Packages nutzen.

 

[Kamikaze]

Auch die meisten anderen Systeme zur Bereitstellung von Software-Packeten würde ich gerne sterben sehen. Und ersetzt durch Lösungen, die die Packete direkt von den Entwicklern beziehen.

Zeige mir den Software-Entwickler, der bereit ist Pakete für diverse BSDs, dutzende kommerzielle Unices und hunderte Linux-Distributionen zu bauen.

So rum funktioniert das einfach nicht.

 

[nihonto]

* Debian - kaputtes OpenOffice Writer

... komisch, bei mir funktioniert's - benutzt Du Sid?

 

[mawei]

Zeige mir den Software-Entwickler, der bereit ist Pakete für diverse BSDs, dutzende kommerzielle Unices und hunderte Linux-Distributionen zu bauen.

Klar, so wird das nicht mehr gehen. Voraussetzung dafür wäre eine Art "Application System Layer" also eine Laufzeitumgebung (oder Virtuelle Maschine). Nur die muesste dann für die verschiedenen Betriebssysteme und Linux-Varianten portiert werden. Die Anwendungsprogramme laufen dann überall, wo die Laufzeitumgebung vorhanden ist.

 

[Kamikaze]

So wie Java zum Beispiel? Funktioniert trotzdem nicht richtig, siehe Eclipse, das mit SWT dann doch jedesmal nativ gebaut werden muss.

 

[mawei]

So wie Java zum Beispiel?

Ja, allerdings mit echter, funktionierender Platfformunabhängigkeit :-)

 

[soul_rebel]

Wie wäre es mit Python?

Da brauch man nur einen Interpreter für. Ich glaub da aber nicht so recht dran. Code sollte halbwegs auf die konkrete Architektur angepasst sein, besonders wenn er schnell sein soll, deswegen wirds immer Compiler geben und immer Binärcode, und der wird sich immer zwischen unterschiedlicen Kernels und C-Libraries unterscheiden und mit der immer komplizierteren Abhängigkeitsverstrickung wird man auch nicht um eine Betriebsystemspezifische Verwaltung rumkommen.

Was nicht heißt, dass ich nicht glaube, dass die BSDs langfristig eine Ports-Metasystem haben könnten.

 

[Kamikaze]

Ich arbeite jetzt schon eine ganze Weile beruflich mit Python. Die Sprache ist schön, aber der Rest ist katastrophal. Alle Versionen sind inkompatibel. Nicht nur bei Major-Sprüngen wie von 2 auf 3, sondern auch bei kleinen Wechseln wie von 2.5 auf 2.6 werden Module umbenannt, Funktionen verschoben usw.

Eine Menge Funktionen sind unter Windows nicht verfügbar. Es gibt dann eigene Module für Windows. Dabei kann man meistens Wrapper konstruieren, damit die Unix-Funktionen transparent auf die Windows-Funktionen abgebildet werden (habe ich Beispielsweise bei ein paar Dateisystem-Funktionen gemacht). Warum wurden die Funktionen nicht gleich mit dem selben Interface geschrieben? Warum sind sie in unterschiedlichen Modulen, wo ihre Existenz sich doch eh gegenseitig ausschließt.

Das sind Dinge die im Interpreter gelöst sein sollten.

Der Bytecode-Interpreter für Perl6 klingt da interessanter, vor allem, da es echte Versuche gibt Bytecode aus mehreren Sprachen zu erzeugen. Das problematischste sind aber oft immer noch die murksigen Windows-Dateisysteme, mit denen man immer wieder Ärger hat. Vor allem weil dann irgendwelche Windows-Programmierer Pfade mit \ angeben (die Sprachen wandeln / alle passend um, mit \ funktioniert das nicht so). Als Unix-Programmierer hat man den Ärger, dass man irgendwelche Dateinamen verwendet, die unter NTFS nicht funktionieren (e.g. mit Datum und Uhrzeit im Namen, dann schmeißt einem Windows die Doppelpunkte um die Ohren).

 

[Daemotron]

Jo, Python hat ein schönes Sprachkonzept, aber abgesehen von den permanenten Inkompatibilitäten zwischen den Versionen ist auch der Interpreter recht katastrophal implementiert (Beispiel: Threads vs. Global Interpreter Lock). Alternative Implementierungen kommen auch nicht richtig aus dem Quark, und einsetzen würde ich sie auch nur ungern - die nächsten Inkompatibilitäten wären vorprogrammiert...

Nichts desto trotz ist die Sprache sehr produktiv. Für Individual-Software finde ich sie ideal (und was fehlt, hat man schnell als Extension in C nachgecoded), aber für Projekte, die über viele Plattformen verteilt lauffähig sein sollen, ist Python recht anstrengend (während bei C & Co. die Antrengung eher im Entwicklungsbereich liegt, ist es bei Python im speziellen und bei allen Interpretersprachen im allgemeinen dann die Maintenance). Plattformunabhängigkeit muss man sich leider immer noch (trotz Perl, Python, Java, Mono & Co.) mit erhöhtem Entwicklungs- und Maintenance-Aufwand erkaufen.

 

[indy]

Ich hatte mal angefangen, ein Metapaketsystem zu bauen, dass YAML-Files einliest und daraus FreeBSD-Ports-Makefiles und SPECs für RPM macht. Da das ganze auf einem Metamodel basiert, kann man das auch recht angenehm in andere Formate exportieren.
Angefangen hatte ich in Python, das war mir dann aber zu umständlich, weshalb ich das in Perl weitergemacht habe - Plattformunabhängigkeit ist also gegeben.

So long...

Der Indy

 

[mawei]

... komisch, bei mir funktioniert's - benutzt Du Sid?

Nein, Lenny.

Das Problem sind mit Word 2000 erzeugte Tabellen. Debians OpenOffice 2.4 zeigt in den meisten Fällen (aber nicht allen) den Inhalt nicht an. Speichert man diese Dokumente dann erneut ab, ist der Inhalt "endgültig" weg und lässt sich auch nicht mehr mit Word oder OpenOffce 3.x anzeigen.

Der GNOME-pdf-viewer ist unter Lenny auch "kaput" - mehrseitige PDF-Dokumente werden in den meisten Fällen nicht gedruckt. Ein ebenfalls auf dem System installiertes KPDF hat diese Probleme nicht.

Wie gesagt, alles Standard-Anwendungen, die solche Probleme auf anderen Systemen nicht zeigen - dafür sind da andere Sachen kaput.