FreeBSD: 16.000 Ports überschritten

chaos

*nix'ler
Ich habe einen Port gefunden bei dem das letzte Release vom 17.08.1995 (!) war.
Wer soll sich um so ein Stück Software kümmern?
Wieso soll man sich um so ein Stück Software kümmern, wenn es immernoch baut/läuft und keine bekannten Sicherheitslöcher enthält?
 

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.
 

Kamikaze

Warrior of Sunlight
Was bringt mir das OFFLINE?

Ich sitze pro Woche 5 bis 6 Stunden (einfach) auf dem Weg zum Kunden im Zug, da ist Offline verfügbare Dokumentation essentiell!
Online Dokumentation hat nichts mit Internet zu tun. Das heißt die Dokumentation ist direkt vom Programm aus aufrufbar.

Es soll Leute geben, die in der Lage sind ein Programm auszuführen und Sourcecode zu lesen!
Da habe ich besseres zu tun.


Du meinst diese distinfo-Datei?
Findet sich diese nach einer Installation im lokalen System oder auch nur online?
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?


Das hast noch "zu was der Maintainer in der Lage ist" vergessen!
Am besten sollten die Maintainer auch noch eine Prüfung ablegen...

Wenn ich einen PR einstelle, dann nach Möglichkeit nur noch mit Patch, ansonsten kommt ja doch nur wieder "Haste mal nen Patch".
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.
 

razoredge

Well-Known Member
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
 

razoredge

Well-Known Member
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
 

marzl

Well-Known Member
Kleine OT TInderbox Frage: Gibt es mittlerweile die Möglichkeit inneralb der tinderbox Ports mit speziellen Optionen zu bauen, ala make.conf (WITH_EXTRAFEATURE=yes)? Pro Port oder nur global?
 

mawei

Well-Known Member
Bei einem FreeBSD Port wird nur gewährleistet, dass der Port kompiliert.Da hört es aber auch schon wieder auf!

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?


- bei Debian hat der Maintainer eine Man Page zu schreiben, wenn keine dabei ist

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.

- bei FreeBSD ist kein Changelog dabei, an Hand dessen zu erkennen ist, wann der jeweilige Maintainer das Paket zum letzten mal bearbeitet hat

... hab ich noch nie vermisst

- bei Debian ist muss eine copyright-Datei dabei sein, damit eindeutig zu erkennen ist, unter welcher Lizenz die Software steht

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.


Was ist Dir lieber?
Ein kompilierender Port oder ein funktionierendes Paket?

Natürlich ein funktionierendes Paket aus einem aktuellen, kompilierenden
Port :D
 

menace

Well-Known Member
Wie soll ein Port denn funktionieren, wenn er nicht kompiliert? Machst du auch Fotos, indem du das Objektiv einer Kamera in die Hand nimmst und "TschudTschuuud"-Laute von dir gibts?
 
T

tib

Guest
Online Dokumentation hat nichts mit Internet zu tun. Das heißt die Dokumentation ist direkt vom Programm aus aufrufbar.
Wenn Du die integrierte Dokumentation meinst, dann sag dass doch einfach!

Da habe ich besseres zu tun.
Das kann nur Deinem Studium zu Gute kommen :)

Am besten sollten die Maintainer auch noch eine Prüfung ablegen...
Am besten eine BSD-Zertifizierung!

Das kommt wenn dein Problem nicht nachvollzogen werden kann.
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?

Aber die Ports sind doch nun so buggy und broken? Klaro:
14.000 BROKEN 215 1,53% aller Ports
15.000 BROKEN 142 0,94% aller Ports
16.000 BROKEN 150 0,93% aller Ports

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! :D


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. :p
 

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.
 

Kamikaze

Warrior of Sunlight
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

Warrior of Sunlight
OpenBSD wäre gar nicht gegen 3D, wenn die Treiber im Kernel laufen würden. Vielleicht wäre Pkgsrc tatsächlich das bessere System, aber wie willst du all die Manpower transferieren?
 

soul_rebel

ist immer auf der flucht
kamikaze schrieb:
OpenBSD wäre gar nicht gegen 3D, wenn die Treiber im Kernel laufen würden.
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!
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 :eek:

kamikaze schrieb:
Vielleicht wäre Pkgsrc tatsächlich das bessere System, aber wie willst du all die Manpower transferieren?
ein konkreter plan, für die umstellung? :
  1. feststellen welchen features den freebsd leuten in pkgsrc fehlen und diese hinzufügen
  2. 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)
  3. freebsd-ports einfrieren (nurnoch sicherheits-patches erlauben)
  4. alle maintainer dazu aufrufen ihre ports zu "portieren", es gibt sogar skripte die automatisch ein pkgsrc-ding von einem freebsd-port erstellen
  5. 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.
  6. 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....
 

Kamikaze

Warrior of Sunlight
Ich sehe das Hauptproblem darin, dass beim wechsel auf Pkgsrc das Paketsystem in andere Hände übergeht. Das würde vielen nicht schmecken.

Was die Intel Treiber angeht, dadurch, dass sie offen sind, laufen sie noch lang nicht im Kernel.
 

soul_rebel

ist immer auf der flucht
Ich sehe das Hauptproblem darin, dass beim wechsel auf Pkgsrc das Paketsystem in andere Hände übergeht. Das würde vielen nicht schmecken.
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....

Was die Intel Treiber angeht, dadurch, dass sie offen sind, laufen sie noch lang nicht im Kernel.
bei freebsd tut ers zuminedest, device i915 bzw. i915.ko
 

Kamikaze

Warrior of Sunlight
Ein Teil der Grafikgeschichte liegt bei Xorg immer im Userland. Selbst ohne 3D unterstützung brauchst du /dev/io.
 
Oben