FreeBSD: 16.000 Ports überschritten
- Ersteller Daniel Seuffert
- Erstellt am
T
tib
Guest
Bei dem betreffenden Programm erfolgt bei einer Option ein unvollständige Ausgabe.
soul_rebel
ist immer auf der flucht
ein guter text....
wenn pkgsrc wie die obsd-ports erst paketieren und dann isntallieren würde, wärs der bringer und könnte imo von allen bsds genutzt werden.
freebsd-ports sind imo von den dreien technisch ab schlechtesten, aber dafür am umfangreichsten, meistens am aktuellsten und haben mehr aktuelle packages.
wenn pkgsrc wie die obsd-ports erst paketieren und dann isntallieren würde, wärs der bringer und könnte imo von allen bsds genutzt werden.
freebsd-ports sind imo von den dreien technisch ab schlechtesten, aber dafür am umfangreichsten, meistens am aktuellsten und haben mehr aktuelle packages.
Online Dokumentation hat nichts mit Internet zu tun. Das heißt die Dokumentation ist direkt vom Programm aus aufrufbar.
Da habe ich besseres zu tun.
Nein, ich meine natürlich den CVS Log. Ich bin mir sicher, wenn du lust hast, kannst du dir das auch irgendwie mit dem Ports Tree ziehen. Wozu ich den als User (oder auch als Maintainer) benötige ist mir aber ein Rätsel. Schließlich passiert als Maintainer ja sowieso nichts an meinen Ports, ohne, dass ich informiert werde.
Bist du irgendwie empfindlich?
Am besten sollten die Maintainer auch noch eine Prüfung ablegen...
Das kommt wenn dein Problem nicht nachvollzogen werden kann. Jedenfalls entspricht es nicht meinen Erfahrungen.
Tohuwabohu!
Active Member
Was soll denn dieser infantile Flame hier!?
@tib
Ich habe nur die *Anzahl* der Programm-Pakete verglichen, nicht die sonstige Qualitaet derer!
@soul_rebel
Klar, kannst du erst paketieren und anschliessend installieren! Nutze sandboxing im Pkgsrc.
@tib
Ich habe nur die *Anzahl* der Programm-Pakete verglichen, nicht die sonstige Qualitaet derer!
@soul_rebel
Klar, kannst du erst paketieren und anschliessend installieren! Nutze sandboxing im Pkgsrc.
Wobei ich persoenich es immer auesserst nervig finde, meine 3 Tinderboxen einen kompletten Lauf fuer einen kleinen Port machen zu lassen. Speziell, wenn sie X11 brauchen. Nach 3 Stunden Kompilierung eine kleine Aenderung als PR einzugeben kann schon aergern :-).
Was tut man nicht alles fuer die User.
gruss
Was tut man nicht alles fuer die User.
gruss
Je nach dem. Ich gehe bei meinen Ports meist auf Nummer sicher zumal sich hauefig ja auch die abhaengigen Ports in der Versionierung geaendert haben. Gerade bei der SDL Umstellung hatte ich da hehre Probleme mit Package-Leichen, die Fehler nicht aufdeckten.
daher lasse ich das lieber mit -cleanpackages durchlaufen, wenn das Zeitfenster zwischen meinen Laeufen mehr als 2 Wochen betraegt.
gruss
daher lasse ich das lieber mit -cleanpackages durchlaufen, wenn das Zeitfenster zwischen meinen Laeufen mehr als 2 Wochen betraegt.
gruss
Was hindert die Ports Maintainer daran, die erstellten Pakete vorher zu testen? Oder anders: Wie realisiert Debian die grössere Chance, dass die Pakete funktionieren?
Vermutlich können die Ports Maintainer auch eine Man Page erstellen und dazupacken - oder noch besser, sie den Entwicklern direkt zuschicken, dann haben alle weniger Arbeit.
... hab ich noch nie vermisst
Wie fragt man das unter Debian ab? Aber zugegeben auf jeden Fall eine sehr sinnvolle Praxis. Andererseits sollte jede Anwendung selber auch eine einfach abzufragende Lizenz-Info bieten.
Natürlich ein funktionierendes Paket aus einem aktuellen, kompilierenden
Port
T
tib
Guest
less /usr/share/doc/<packetname>/copyright
Packetname in der bash abfragen: dpkg -S $(which Programmname)
Packetname in der zsh abfragen : dpkg -S =Programmname
T
tib
Guest
Wenn Du die integrierte Dokumentation meinst, dann sag dass doch einfach!
Das kann nur Deinem Studium zu Gute kommen
Am besten eine BSD-Zertifizierung!
Wenn Du einen Maintainer auf ein neues Upstream Release aufmerksam machst,
was soll da nicht nachvollzogen werden können?
Daniel Seuffert
Well-Known Member
Unter 100 BROKEN Ports!
Aus Anlass der Feierstunde wärme ich wie angedroht diesen thread wieder auf und verkünde feierlich, daß die FreeBSD Ports die Schallmauer von 100 BROKEN Ports heute unterschritten haben (die ganz frühen Anfänge wir natürlich absichtlich ausser acht, bevor der erste Krümelkacker hier auftaucht).
Wie schrieb ich im Eingangspost?
Das sagt mir soeben Freshports:
Port count 16283
Broken 83
Deprecated 165
Forbidden 6
Vulnerable 44
Expired 34
Set to expire 138
16.283 BROKEN 83 0,51% aller Ports
Bevor einer fragt: Die anderen abgelaufenen Ports (34) können grad nicht gelöscht werden, weil sie z.B. als dependency in anderen Ports hängen usw.
Ach bevor ich es vergesse zu erwähnen: FreeBSD Ports are dying!
P.S.: Ich stell noch irgendwann ne Flasche Taittinger Brut Reserve in den Klimaschrank für den Tag, an dem GNATS aus den Ports fliegt.
Aus Anlass der Feierstunde wärme ich wie angedroht diesen thread wieder auf und verkünde feierlich, daß die FreeBSD Ports die Schallmauer von 100 BROKEN Ports heute unterschritten haben (die ganz frühen Anfänge wir natürlich absichtlich ausser acht, bevor der erste Krümelkacker hier auftaucht).
Wie schrieb ich im Eingangspost?
Das sagt mir soeben Freshports:
Port count 16283
Broken 83
Deprecated 165
Forbidden 6
Vulnerable 44
Expired 34
Set to expire 138
16.283 BROKEN 83 0,51% aller Ports
Bevor einer fragt: Die anderen abgelaufenen Ports (34) können grad nicht gelöscht werden, weil sie z.B. als dependency in anderen Ports hängen usw.
Ach bevor ich es vergesse zu erwähnen: FreeBSD Ports are dying!
P.S.: Ich stell noch irgendwann ne Flasche Taittinger Brut Reserve in den Klimaschrank für den Tag, an dem GNATS aus den Ports fliegt.
soul_rebel
ist immer auf der flucht
ne fusion mit pkgsrc fände ich trotzdem geil...
Daniel Seuffert
Well-Known Member
Prinzipiell hätte es sicher Vorteile von der Praktikabilität her, zumindest für Nutzer von mehreren/allen BSD-Derivaten. Zudem könnte man manpower, build-Kapazitäten, Bandbreite, storage usw. besser ausnützen, Dreifacharbeit oder gar noch Schlimmeres (man denke nur an Ports/packages alleine in FreeBSD nebst pbi in PC-BSD) würde vermieden oder zumindest reduziert etc. Aber das geht aus tausend Gründen nicht.
Und soooo weit sind nun pkgsrc und FreeBSD Ports nun wirklich nicht voneinander entfernt, da sind die OpenBSD Ports eher weiter "entfernt". Und wie ich bereits erwähnte flossen bereits seit 1997 nach der Übernahme der Ports in NetBSD (die wurden ja nur umbenannt, weil Ports in NetBSD damals begrifflich schon anderweitig besetzt war, ein gewisser Poster im thread hier sollte sich erstmal schlau machen) viele Sachen von NetBSD wieder nach FreeBSD zurück und werden es zum Beispiel auch nach der Vollendung der Arbeit von Jörg wieder tun.
In gewissen Massen belebt Konkurrenz das Geschäft, alles hat Vor- und leider auch Nachteile.
Und soooo weit sind nun pkgsrc und FreeBSD Ports nun wirklich nicht voneinander entfernt, da sind die OpenBSD Ports eher weiter "entfernt". Und wie ich bereits erwähnte flossen bereits seit 1997 nach der Übernahme der Ports in NetBSD (die wurden ja nur umbenannt, weil Ports in NetBSD damals begrifflich schon anderweitig besetzt war, ein gewisser Poster im thread hier sollte sich erstmal schlau machen) viele Sachen von NetBSD wieder nach FreeBSD zurück und werden es zum Beispiel auch nach der Vollendung der Arbeit von Jörg wieder tun.
In gewissen Massen belebt Konkurrenz das Geschäft, alles hat Vor- und leider auch Nachteile.
Knackpunkt ist für mich, dass die meisten wohl genau ein oder 2 BSD einsetzen und sich entsprechend normalerweise auch nur um Ports für ein BSD kümmern wollen. Zumindest geht es mir so. Ich denke ein Multi-Plattform Ansatz wie Pkgsrc benötigt deutlich mehr soziale Interaktion, was für mich die Hemmschwelle deutlich heben würde (Bitte korregiert mich, wenn ich falsch liege. Ich habe Pkgsrc noch nie verwendet). Bei FreeBSD gebe ich meine PRs ab und normalerweise ist damit alles erledigt.
soul_rebel
ist immer auf der flucht
habe pkgsrc bis jetzt auch nur kurz verwendet... aber einige sachen gefielen mir sehr gut.
@kamikaze: ich glaube auch nicht dass auf den comitter mehr arbeit hinzukommt, das paketsystem sollte ja eigentlich so konzipiert sein, dass sachen die auf einer platform laufen, es auch auf anderen tun. und ansonsten kümmert sich sicherlich jemand anderes darum. als freebsd-port-comitter muss ich ja auch keine testlauf auf einer 4.11 maschine machen. sollte es da fehler geben wird einem das gesagt und geholfen. so wird das bei pkgsrc auch sein denke ich.
wie gesagt, von struktur hat pkgsrc einige vorteile gegenüber den freebsd-ports, aber freebsd-ports sind halt größer und haben mehr manpower...
m.e. wäre eine fusion für alle beteiligten ein gewinn.
mit openbsd ist das sicher noch eine andere sache, da die ja nur freie software in ihren ports wollen (was sehr respektabel ist) und außerdem gegen 3d-beschleunigung, spiele und ähnliches sind (ich glaube man hätte probleme die obsdler zu überzeugen warum quake3 in die ports muss) und außerdem die netbsdler nicht mögen...
aber freebsd und netbsd könnten das schaffen wenn sie wollten....
@kamikaze: ich glaube auch nicht dass auf den comitter mehr arbeit hinzukommt, das paketsystem sollte ja eigentlich so konzipiert sein, dass sachen die auf einer platform laufen, es auch auf anderen tun. und ansonsten kümmert sich sicherlich jemand anderes darum. als freebsd-port-comitter muss ich ja auch keine testlauf auf einer 4.11 maschine machen. sollte es da fehler geben wird einem das gesagt und geholfen. so wird das bei pkgsrc auch sein denke ich.
wie gesagt, von struktur hat pkgsrc einige vorteile gegenüber den freebsd-ports, aber freebsd-ports sind halt größer und haben mehr manpower...
m.e. wäre eine fusion für alle beteiligten ein gewinn.
mit openbsd ist das sicher noch eine andere sache, da die ja nur freie software in ihren ports wollen (was sehr respektabel ist) und außerdem gegen 3d-beschleunigung, spiele und ähnliches sind (ich glaube man hätte probleme die obsdler zu überzeugen warum quake3 in die ports muss) und außerdem die netbsdler nicht mögen...
aber freebsd und netbsd könnten das schaffen wenn sie wollten....
soul_rebel
ist immer auf der flucht
wie schon öfter erwähnt gibt es zumindest für intel grafikkarten komplett freie treiber. das sind zwar nur onboard karten, aber die neuen sollen auch leistungsmäßig zumindest ans mittelfeld von ati und nvidia rankommen und es gibt inzwischen desktop-boards mit den chips drauf!kamikaze schrieb:
aber netbsd hats bis jetzt ja auch nicht hinbekommen. bei dragonfly haben sie soweiti ich weiß die freien treiber noch nicht portiert, arbeiten dafür hart daran die freebsd-nvidia-blobs mit gefrickel zum laufen zum kriegen
ein konkreter plan, für die umstellung? :kamikaze schrieb:
- feststellen welchen features den freebsd leuten in pkgsrc fehlen und diese hinzufügen
- auf den clustern als erstes packagebuilds des jetzigen pkgsrc bauen lassen um zu gucken ob alles installiert (sollte eigentlich gehen, denn netbsd lässt pkgsrc auch auf freebsd systemen testen)
- freebsd-ports einfrieren (nurnoch sicherheits-patches erlauben)
- alle maintainer dazu aufrufen ihre ports zu "portieren", es gibt sogar skripte die automatisch ein pkgsrc-ding von einem freebsd-port erstellen
- ein update skript bereitstellen, was den aktuellen pkgsrc zweig zieht und alle momentan installierten freebsd-pakete parallel aus pkgsrc baut, danach in single-usermode geht, alle installierten pakete und die freebsd-pkg-tools entfernt, die netbsd-pkg_tools installiert und die vorgebauten pakete installiert.
- ab der nächsten version die pkgsrc-pkg-tools in base mitliefern
punkt 4 würde wahrscheinlich am längsten dauern, aber innerhalb eines release-zyklusses sollte das drin sein.
tja... träum... aber dann müsste halt jeder mal aufhören sein eigenes süppchen zu kochen....
edit: viel von dem jetzigen stress wie X11BASE und LOCALBASE mergen, und so hätte man sich dadurch ersparen können, und /usr/pkg klingt sowieso einleuchtender.
durch diese trennung könnte man sogar seine kompletten pakete aus pkgsrc parallel installieren und durch ändern von PATH gucken ob alles geht....
soul_rebel
ist immer auf der flucht
man könnte es auch als kolaboration ansehen. da danach mehr freebsd-user das system nutzen würden, wäre das sicher auch von netbsd her akzeptabel....
bei freebsd tut ers zuminedest, device i915 bzw. i915.ko