FreeBSD: Ende von pkg_install am 1. September

Yamagi

Possessed With Psi Powers
Teammitglied
Hallo,
seit knapp 21 Jahren stellte pkg_install (auch als pkg_* bekannt) FreeBSD Paketmanagement da. Sei es für direkt per pkg_add installierte Binärpakete, oder aber über die Ports selbst gebaute und anschließend automatisch installierte Pakete. Da es inzwischen restlos überholt und nicht mehr zeitgemäß ist, wurde in den letzten Jahren mit pkg aka pkgng ein deutlich moderner Nachfolger entwickelt. Nachdem pkg nun in FreeBSD 10.0 bereits das Standardtool für Paketmanagement und die Installation von Ports ist, hat man sich entschlossen die Unterstützung fpr pkg_install am 1. September 2014 endgültig einzustellen. Das bedeutet, dass auch die Nutzer von FreeBSD 9.x und 8.x bis dahin zur Installation von Ports und / oder Binärpaketen auf pkg umstellen müssen.

Der Verzicht auf pkg_install bedeutet, dass man nicht mehr zu diesem kompatibel bleiben muss. Dies wiederum ermöglicht eine ganze Reihe bisher nur theoretischer Möglichkeiten von pkg praktisch zu nutzen oder zu entwickeln:
- Subpackages, welche Probleme wie "php installiert kein Apache-Module" beheben können.
- Weitere Metadaten in Form von "pkg install webserver", was einen Webserver installiert.
- Sinnvolleres und zuverlässigeres Dependency-Tracking

Die Ankündigung:
Code:
There comes a time in the life cycle of just about every software package
that it has bee re-evaluated, refreshed, deprecated or just retired.

It is time that we bid farewell to the old pkg_* software that has been
part of FreeBSD since the beginning, and has served us well.  After years
of development, testing, and playing, pkg(8) has become a suitable
replacement.

Pkg is the Next Generation package management tool for FreeBSD.  It is the
replacement for the current pkg_info/pkg_create/pkg_add tools that ports
use to register local packages and which provide remote packages.  Its main
goals are to facilitate remote binary package upgrades.  It also works with
ports without remote binary packages.

Pkg, combined with the quarterly release package sets, enables easy
installation and safe upgrades for binary packages.  Signed, binary
packages are available for all supported FreeBSD releases on the i386 and
amd64 platforms from pkg.freebsd.org.  Additionally, for those compiling
ports from source, pkg's new database format gives more fine-grained
querying and management of installed software.

New features on the drawing board, like automatic pkg-plist generation,
sub-packages, creating multiple packages containing different parts of a
port from one build process, and flavours, being able to ask for e.g. a
webserver, without directly specifying a specific one, cannot be
implemented in the old pkg_* tools and those plans are currently on hold.

You are not obligated to switch to binary packages, if you still prefer to
compile your own ports, it is a simple matter of installing ports-mgmt/pkg,
run pkg2ng, add WITH_PKGNG=yes to your make.conf and use pkg <action>
instead of pkg_<action>.

You can read more about pkgng on the FreeBSD wiki,
https://wiki.freebsd.org/pkgng.

The decision has been made to allow the old pkg_* software to be EoL'd 6
months from now, at September 1, 2014 in all active FreeBSD branches.

Please start testing pkg(8) in your test environments before taking it
live, you will find the benefits of full binary updates for your ports to
be beneficial in a very short amount of time.  Even if you prefer to
compile from source, you will still reap the benefits of the modern
packaging system.

http://blogs.freebsdish.org/portmgr/2014/02/03/time-to-bid-farewell-to-the-old-pkg_-tools/
 
portmaster und pkg machen ihr Ding seit Monaten. Auch pkg_libchk funktioniert. Wer will da noch pkg_*?
 
Ich muss es vielleicht anderst erklären...

FreeBSD 9 wurde mit "pkg_add" ausgeliefert und soll dies doch, meiner Meinung nach, bis Ende Support der Reihe 9 auch so handhaben. Ich bin jetzt gezwungen, auf diesen Servern alle Pakete zu löschen und wieder zu installieren. Dies hat in meinem Fall natürlich auch den Vorteil, dass ich direkt auf "poudriere" umstellen kann. Sollte keine grosse Sache sein aber ist halt doch wieder mit Aufwand und auch Downtime verbunden.
 
Jepp. Ich habe zwar im letzten Jahr schon nach und nach einen Großteil migriert, aber einige Klopper fehlen mir auch noch. Immerhin eine Chance zum Aufräumen. Aber ich verstehe auch portmgr@. pkg_install bis zum Ende von 9.x zu unterstützen, wären bestenfalls noch 30 Monate. Dann lieber jetzt einmal ins kalte Wasser und dafür umso früher ein besseres pkg haben.
 
Wofür müßt ihr denn alle Ports neu bauen, wenn ihr auf pkg umstellt?
Ich habe das zwar nur zweimal Testweise gemacht, aber da war das mit einem Umbau der Datenbank mit pkg2ng oder ähnlich getan.
 
Wofür müßt ihr denn alle Ports neu bauen, wenn ihr auf pkg umstellt?
Bei mir z.B. sind die Fileserver auch mit Samba installiert. Da die User natürlich von Windows kommen, muss ich AD Support mit Samba bauen. Ich kann in diesem Fall nicht die offiziellen PKG Pakete verwenden. Es sind noch 2-3 weitere Ports mit Anpassungen. Diese kann man aber in der Zwischenzeit mit "poudriere" sehr gut verwalten/bauen.
 
Bei mir z.B. sind die Fileserver auch mit Samba installiert. Da die User natürlich von Windows kommen, muss ich AD Support mit Samba bauen. Ich kann in diesem Fall nicht die offiziellen PKG Pakete verwenden. Es sind noch 2-3 weitere Ports mit Anpassungen. Diese kann man aber in der Zwischenzeit mit "poudriere" sehr gut verwalten/bauen.
Es zwingt dich ja keiner dazu, die fertigen Pakete zu benutzen. Durch pkg2ng wird nur die Paketdatenbank ins neue Format gebracht. Wenn du dann noch WITH_PKGNG=yes in die make.conf einträgst, kannst du den Portstree samt portmaster und portupgrade weiter benutzen wie bisher.
 
Durch pkg2ng wird nur die Paketdatenbank ins neue Format gebracht.
Ja das ist schon richtig nur habe ich beim konvertieren etliche Fehler und wer weiss was da nicht noch alles im Hintergund "vermurkst" wird. "pkg" Pakete enthalten ja sehr viel mehr Informationen. Ne dann lieber alles löschen und die Pakete von Grund auf richtig mit "pkg/poudiere" bauen. Hat ja so auch den Vorteil, dass man dann nicht mehr auf dem produktiven Servern kompilieren muss.
 
Ja das ist schon richtig nur habe ich beim konvertieren etliche Fehler und wer weiss was da nicht noch alles im Hintergund "vermurkst" wird. "pkg" Pakete enthalten ja sehr viel mehr Informationen. Ne dann lieber alles löschen und die Pakete von Grund auf richtig mit "pkg/poudiere" bauen. Hat ja so auch den Vorteil, dass man dann nicht mehr auf dem produktiven Servern kompilieren muss.
Das kommt aber wahrscheinlich daher, dass die plists der installierten Pakete nicht korrekt waren. Neuinstallieren ist aber sicherlich nicht die schlechteste Lösung.
 
Kann nach der Umstellung pkg manuell installierte und als Abhängigkeit gezogene Pakete noch korrekt auseinanderhalten? Ansonsten würde das autoremove nur bei anschließend installierten Paketen korrekt funktionieren.
 
Kann nach der Umstellung pkg manuell installierte und als Abhängigkeit gezogene Pakete noch korrekt auseinanderhalten? Ansonsten würde das autoremove nur bei anschließend installierten Paketen korrekt funktionieren.
Mhhh, nein, da das nicht in der alten Paketdatenbank mit drin war nicht.
Aber es sollte funktionieren, wenn man alle außer den Leaf-Paketen als "auto" markiert. Naja, 100% sicher sein kann man sich dann auch nicht, aber einen Versuch (auf einem nicht-produktiven Rechner) ist es wert.
 
Mal eine kleine Frage, da wir schon bei Upgradeaufwand sind. Bei pkg gibt es ja noch immer viel Updates. Gibt es eigentlich eine Policy was FreeBSD und Versionen von pkg betrifft? Oder ist das alles schon garantiert abwärtskompatibel?

Wäre cool, wenn jemand was dazu weiß, dann kann man da besser planen und für die Zukunft vorsorgen.
 
Mal eine kleine Frage, da wir schon bei Upgradeaufwand sind. Bei pkg gibt es ja noch immer viel Updates. Gibt es eigentlich eine Policy was FreeBSD und Versionen von pkg betrifft? Oder ist das alles schon garantiert abwärtskompatibel?

Wäre cool, wenn jemand was dazu weiß, dann kann man da besser planen und für die Zukunft vorsorgen.
Wie meinst du das?
 
Also ich finde es schon reichlich gewagt, einfach so, mitten drinn den Paket-Manager auszutauschen. Bei größeren Installationen mit eigenen Tools und diversen Scripten kann solch eine Änderung schon komplikationen hervorrufen. Da kann es schon einen Unterschied machen ob ich 6 Monate oder 30 habe. Stößt bei mir auf Unverständniss.
 
Na ja mit "poudriere" kannst du ja alles vorbereiten und die Pakete bauen, so wie du willst. Dann alles löschen mit "portmaster" und die Pakete wieder installieren mit "pkg". Dies sollte eigentlich dann nicht so ein grosses Problem sein. Ich z.B. habe die "config" File welche unter "/usr/local/etc" sind in "svn" eingecheckt.
 
Zurück
Oben