[FreeBSD] pkgng: Tester gesucht!

Yamagi

Possessed With Psi Powers
Teammitglied
Wie viele Nutzer in diesem Forum sicher wissen, ist das Management von Binärpaketen unter FreeBSD derzeit suboptimal. Es hat viele Gründe, aber hauptsächlich zu nennen sind dort 2:

- Die Paketdatenbank in /var/db/pkg speichert nicht alle notwendigen Informationen, sie ist langsam, ineffizient und fehleranfällig.

- Die im Basissystem enthaltenen pkg_* Tools sind ebenso fehlerhaft und bieten nicht genug Funktionen.

In der Vergangenheit gab es mehrere Versuche um beide Nachteile herumzufrickeln. Reine Port-Tools wie Portmaster wurden erweitert, um auch Binärpakete verwalten zu können. Portupgrade implementierte seine eigene Datenbank. Dennoch erreicht man nie die Klasse, die Nutzer voin Linuxdistributionen gewohnt sind. Aus diesem Grund wurde in den letzten Monaten der Binärpaketmanager "pkgng" geschrieben. Die Designziele sind:

- Ersetze /var/db/pkg durch eine neue Datenbank, die schneller und robuster als die derzeitige Struktur ist. Die Wahl fiel auf eine sqlite-Datenbank.

- Erlaube weitere Metadaten und verändere das Paketformat so, dass es diese Metadaten speichern kann. Diese Metadaten werden nun in Form von YAML-Dateien gespeichert, denn dieses Format ist problemlos von Menschen lesbar und auch maschinell leicht zu handhaben.

- Entkoppele das Basissystem von den Ports. So wie ich es verstanden habe, soll pkgng nicht mehr Teil des Basisystems werden, viel mehr ein integraler Bestandteil der Ports. Es muss im Rahmen der Installation des Portstree installiert werden. Vielleicht kann hier noch jemand etwas zu sagen, der mit der Materie vertrauter ist.

- Stelle ein Interface bereit, was sich an gängigen Linux-Paketmanagern orientiert. pkgng ist daher ein Hybrid geworden, der Funktionen aus apt, yum, packman und einigen anderen Tools aus der Linuxwelt kombiniert.

Die unten stehende E-Mail erläutert pkgng noch ein wenig genauer und gibt Hinweise zu Benutzung des Tools. Es ist geplant, pkgng 1.0 gemeinsam mit FreeBSD 9.1 auszuliefern, was für den Sommer geplant ist. BITTE BEACHTET: Ist die Die Paketdatenbank muss konvertiert werden! Die E-Mail sagt nichts dazu, aber es scheint, dass der Weg zurück zu den bisherigen pkg_* Tools damit versperrt wird!

Code:
Hi,

pkgng has just reached the beta phase, and has now found its way to the
ports tree (disabled by default).

1/ Why pkgng?
------------

Our current pkg_install tools are showing their age, are hard to maintain,
and they lack features:

- missing metadata
- no upgrade support
- no repository support
- no fine dependency tracking
- no modern binary package management
- and many others

Having old tools makes it hard to improve the ports infrastructure, as a
result lots of hacks have found their way into the different Mk/bsd.*.mk
files to work around pkg_install limitations plus there are lots of hacks
in the packages metadata itself such as @comment which are not comments,
and so forth.

We have people writing tools to improve the situation (portmaster and
portupgrade to name two), but they are limited by and can become quite
complicated to maintain because of the pkg_install limitations.

2/ What it is?
--------------

It is a tool that is designed to replace pkg_install and provide modern
features to advance package management on FreeBSD.

It has been done with compatibility in mind.  Most of the ports tree are
able to build on pkgng without modification (21500 successful packages is
the highest pkgng score so far).  The missing ones will be easily fixed
with pkgng in ports.

It has been done with ease of migration in mind.  It is easy to migrate
from pkg_install to pkgng.  (Please note that going backwards is not
possible.)

It has been done with FreeBSD features in mind: it supports chroot, jails,
rcng, etc.

It has been done with scripting features in mind: 'pkg query' will allow
you to query almost everything from the pkgng database in a script friendly
way.

It has been done with improvement in mind: it doesn't require a privileged
account to create packages with root files in it; it is already able to
package from a stage/fakeroot/name_it_like_you_want directory; it is also
able to fake the package creation to directly install the package from that
fake/stage/whatever directory.

It has been done with human readability in mind: the new metadata is
stored in YAML format; the plist keywords can be extended with YAML (for
the ports).

It has been our thinking that the pkg binary is not able to please
everyone's needs, so it has been written on top of a library which can be
used by any other third party tools.  (Think about packagekit, or ruby
binding for portupgrade for example, or any other usage like these).

pkgng is the result of my long studies and reflection about packaging
(studying what is done elsewhere: apt/dpkg, yum/rpm, pacman, aix, solaris,
netbsd, openbsd) and how to have something that tries to take the good
ideas from them, but tries not to take the *over engineered* complicated
parts. And most importantly, tries to do it the FreeBSD way: which means
it should work with the ports tree as-is (and help improve it in the future).

3/ Roadmap
----------

We plan a very long beta phase with lots of beta versions, released as
often as possible to ease testing and help improve the tool as much as
possible.

The goal, now that we are in beta is to not break anything for users, which
means that pkgng will be able to safely upgrade itself.  (No real breakage
occurred during the alpha phase; expect even less in beta.)

Most of the big features are implemented, so now if you have a
revolutionary idea that breaks everything, it won't find its way into pkgng
1.0.  You can still provide it for pkgng 2.0.

1.0 is not revolutionary because of the way that it is full of workarounds
to allow compatibility with the current ports tree.  At some future time
(TBD), once we have dropped pkg_install support, things will be able to
move forward faster.

pkgng will live in the ports tree, so it will evolve with the
infrastructure, allowing us not to have to wait for the EOL of a release to
be able to move forward to new features.

The library API is currently not considered stable; it will be designated
stable as of pkgng 2.0.  Therefore, if you are going to use the library in
a third party project, you can expect some breakage from time to time.  Of
course, we will avoid breakage as much as possible.

The plan is to have pkgng 1.0 ready and rock solid for 10.0-RELEASE and
9.1-RELEASE.

The more testers/contributors we have, the faster we can go, and the faster
we go, the faster we can drop pkg_install and improve our port
infrastructure.

(Note: due to limitations in FreeBSD 7.x, we do not plan to backport
there.)

4/ pkgng itself
----------------

pkg add: add packages the old way (should be avoided by users)

pkg audit: audit the installed packages for vulnerabilities

pkg autoremove: interactively propose packages to be removed that were
installed automatically (as a dependency) and not depended on anymore

pkg check: check the installed packages database, prompting for
inconsistency and proposing to try to fix it

pkg clean: cleanup the package cache from binary installation (from
repositories)

pkg delete: deinstall packages

pkg info: query information from the installed packages in a user-friendly
way

pkg install: install packages from a remote repository

pkg query: query information from the installed packages in a
script-friendly way

pkg register: register packages in the database, synchronising the files
from a fake/stage directory, or with already installed files (like
currently with ports)

pkg search: search the remote database for packages

pkg update: update the remote repositories databases

pkg updating: scan the installed ports and show all UPDATING entries that
affect one of the installed ports (same as old pkg_updating)

pkg upgrade: perform a full binary upgrade of the installed packages

pkg version: determine whether package(s) need to be updated (same as old
pkg_version)

pkg which: determine which package owns a file

pkg2ng: convert a pkg_install installed database to a pkgng installed
database (you would need the ports tree for pkg2ng to be able to gather
missing information about packages)


Sample output of pkg info:

$ pkg info -f libreoffice:
Name           : libreoffice
Version        : 3.4.4
Origin         : editors/libreoffice
Prefix         : /usr/local
Categories     : editors
Licenses       : MPL & LGPL3
Maintainer     : office@FreeBSD.org
WWW            : http://www.libreoffice.org/
Comment        : Full integrated office productivity suite
Options        :
        DEBUG: off
        GNOME: off
        GTK: on
        JAVA: off
        KDE4: off
        MMEDIA: off
        PYUNO: off
        SDK: off
        SYSTRAY: off
        WEBDAV: off
Flat size      : 319 MB
Description    :
LibreOffice is the free power-packed Open Source personal productivity suite for
Windows, Macintosh and Linux, that gives you six feature-rich applications for
all your document production and data processing needs: Writer, Calc, Impress,
Draw, Math and Base.

WWW:    http://www.libreoffice.org/

5/ what is missing
------------------

- for 1.0:

 * currently the user handling is done using the @exec/@unexec scripts from
 the ports; we need to finish the switch to the pw_/gr_util API to have
 cleaner handling.

 * better error reporting; lots of error/warning messages are currently
 technical and need to be improved to become more user-friendly.

 * better documentation; pkgng does a lot of things (more than what is
 described here) and needs to be documented.  We lack enough native English
 speakers that are able to correctly document everything.

 * bug hunting and fixing.

- for future:

 * capsicum: during EuroBSDCon some ideas were shared on how we can
 capsicumize pkgng, and more generally, increase security in package
 management; we need to have more thought about this subject.

 * improved arch support; currently pkgng is able to prevent installing
 amd64 packages into an arm box for examples, but we can go further and
 have real arch handling -- packaging noarch packages only once for all
 architectures (shell scripts, data, etc) and share them between the
 repository.  This would reduce the size of the repositories and speed up
 the packages building process.

 * incrementally updated packages (diff packages): this is a really
 complicated task but could be done, would need a clean design.

 * abstract/alternative packages (e.g. "provide http_server")

 * having a real sat solver for the dependency tree.  Currently we have a
 really simple and minimalistic solver which works well but if we can to go
 to an even finer package management we would need a real solver.

 * many more to join the project to share your ideas.


Keep in mind that in pkgng, every thing should be and will remain simple, so
when you come up with ideas, try providing a simple and clean design :)

to use pkgng:

echo WITH_PKGNG=yes >> /etc/make.conf
make -C /usr/ports/ports-mgmt/pkg install clean

Some links: 
http://wiki.FreeBSD.org/pkgng
http://github.com/pkgng/pkgng

Note that on github you can find a patch for portmaster (against 3.10)

On behalf of the pkgng team
Bapt
 
Du brauchst kein sqlite extra installieren. Der sqlite-Treiber ist in pkgng selbst erhalten.
 
pkg_* kann danach in der Tat nicht mehr benutzt werden, weil die Tools weiterhin auf /var/db/pkg zugreifen dort aber nicht mehr die aktuellen Informationen stehen, sondern den Stand haben, als auf pkgng migriert wurde. Aktuell ist also nur noch die SQLite Datenbank.
Dankenswerterweise ist die Syntax aber soweit ich das bisher gesehen habe, zu fast 100% kompatibel mit der Syntax der bereits vorhanden pkg_* Tools. Aus "pkg_info -Lx firefox" wird "pkg info -Lx firefox", hier muss jeweils nur der "_" weggelassen werden.

pkgng soll zumindest mittelfristig in den Ports bleiben, weil es gerade am Anfang noch eine Menge Entwicklungsarbeit gibt und über die Ports einfach schneller aktualisiert werden kann. Wäre pkgng 1.0 im Basissystem von 9.1 vorhanden, müsste man also für die 1.1 auf FreeBSD 9.2 warten, was mehrere Monate dauert. Es ist also zu begrüßen, dass es im Portstree verweilen wird.
Der Portstree selbst muss dazu minimal angepasst werden: Unterhalb von Mk/ werden die Makefiles auf pkgng getrimmt.

Portmaster kann auch weiter benutzt werden, hierzu muss es allerdings gepatcht werden (Patch auf Github verfügbar).

Bevor ich letztens meinem Notebook ne SSD gegönnt habe und deswegen das System einmal neu aufgesetzt habe, habe ich knapp 2 Monate pkgng benutzt und obwohl es noch Alphastatus hatte, hat es sich gelohnt, das pkgng System ist durch die Datenbank viel schneller und mit der Option "pkg autoremove" kann man den Rechner schön aufgeräumt hinterlassen, wenn man mal Pakete deinstalliert.

Ich kann also nur raten, pkgng auszuprobieren, ein paar kleine Bugs hatte die Alpha noch, aber alle, die ich gemeldet habe wurden vom pkgng Team innerhalb von Minuten / Stunden gefixt und kaputt war auch nie etwas, die Datenbank scheint sehr solide zu sein.
 
Und die Ports kann man weiter parallel benutzen?
Ja, wenn man, wie Bapt in seiner E-mail schreibt, in der /etc/make.conf die Variable
Code:
WITH_PKGNG=yes
setzt. Anscheinend werden die make-Skripte des Ports-Systems bei der Installation von Pkgng entsprechend gepatcht.
 
Wie konvertier ich denn jetzt meine Datenbank?

edit: aha, pkg2ng heißt das Zauberwort und ist auch installiert...
 
Zuletzt bearbeitet:
ui, bei der Konvertierung meckert er schon gehörig, mal schauen, wie es danach aussieht.
 
Öhm, ist das ein Scherz, der kann keine Pakete im alten Format hinzufügen? Das heißt ich kann garkeine Pakete von Packagesites ziehen gerade?
Stand das im Kleingedruckten?

edit: ah ok, es gibt andere Packagesites...
 
Oh nein, es scheint kein Handling von Konflikten zu können, wie z.B. pkg_upgrade. Außerdem sind die Repositories hoffnungslos veraltet. Er will angeblich trotzdem irgendwas aktualisieren, woran er scheitert -.-

Irgendwie sieht es toll aus (er sagt einem sofort was er plant und fragt nach Bestätigung), installieren tuts aber anscheinend nicht so richtig...
 
Die Sache ist halt, dass das Test-Repository ein komplett eigenes Repo ist und die Pakete entsprechend zusätzlich zu den vorhandenen Repos gebaut werden müssen. Ich weiß nicht, wie es derzeit geregelt ist, aber ich könnte mir gut vorstellen, dass das Testrepo keine oder nur wenige Aktualisierungen bekommen.
 
Die Sache ist halt, dass das Test-Repository ein komplett eigenes Repo ist und die Pakete entsprechend zusätzlich zu den vorhandenen Repos gebaut werden müssen. Ich weiß nicht, wie es derzeit geregelt ist, aber ich könnte mir gut vorstellen, dass das Testrepo keine oder nur wenige Aktualisierungen bekommen.

Ja, ist halt nur ziemlich sinnlos, weil ich dann die pkg tools ja garnicht testen kann im Alltagsbetrieb (pkg update, pkg upgrade, pkg install ....). Jetzt muss ich halt die Ports nutzen und kann ganz oft pkg info machen :rolleyes:


Wie setzt ich denn ein eigenes Repo auf?

https://github.com/pkgng/pkgng#pkgcreate
 
pkg create ist ja toll, um alle installierten Programme als Pakete zu bauen. Aber ich will ja Pakete installieren. Dazu muss ich sie erstmal bauen. Aber ich muss sie doch nicht auch gleich installieren, oder? Dann wäre ich doch wieder bei den ports...
 
Dazu gab es etwas in der Diskussion auf den Mailinglisten:
Code:
> What about pkgng support in tinderbox?
> 

beat and I are working on it, just some typos left to figure out, should be
there pretty much soon.
Die Tinderbox sollte also bald angepasst sein. Für andere Methoden Pakete zu bauen muss man dann mal schauen und eventuell die entsprechenden Modifikationen selbst vornehmen.
 
Gibt es jetzt eigentlich irgendwo ein (aktuelles) Repo? Sonst kann ich außer pkg info halt nichts testen...
 
Wie viele Nutzer in diesem Forum sicher wissen, ist das Management von Binärpaketen unter FreeBSD derzeit suboptimal. Es hat viele Gründe, aber hauptsächlich zu nennen sind dort 2:

- Die Paketdatenbank in /var/db/pkg speichert nicht alle notwendigen Informationen, sie ist langsam, ineffizient und fehleranfällig.

- Die im Basissystem enthaltenen pkg_* Tools sind ebenso fehlerhaft und bieten nicht genug Funktionen.

Also ich sehe das Suboptimale, um nicht zu sagen, das Unzulängliche darin, daß die stable-packages einfach nie vollständig sind, so wie die release-packages. Es ist zunächst klar, daß keiner auf dem Stand der release-packages bleiben will. Aber die stable-packages sind einfach unvollständig, manchmal fehlen sogar wichtige metaports, wie nicht mehr und nicht weniger z.B. xorg, gnome2, kde4, etc, so daß man dafür z.b. eben kein "pkg_add -r kde4" machen kann. Mögliche Lösung für das Problem z.B. ein "portmaster --packes-if-newer kde4" oder "portinstall -P kde4".
Und dann wird man schnell merken, daß unzählige Packages gar nicht existieren und man in eine Kompilierorgie hineingezogen wird, die man durch Verwendung von Packages gerade vermeiden will! Hinzu kommt noch, daß dann einige packages auch noch fehlerhaft sind, so daß man diese dann doch als Ports neukompilieren muß.
Ich brauche kein neues Packagemanagement-Tool, wenn kein Server existiert, auf denen nicht alle Packages vorhanden sind, die ich brauche.
Wieso sind die release-packages immer vollständig, die stable-packages aber nicht? Oder gibt es einen tollen Server mit aktuellen und vollständigen und fehlerfreien Packages, den ich nicht kenne?
Ich habe sogar schon überlegt, auf pbi's umzusteigen, dafür gibt es den pbi-manager. Hat das schonmal jemand ausprobiert?
 
Bisher unterstützte das FreeBSD Projekt (genauer gesagt portmgr@) nur die RELEASE-Packages offiziell. Alles andere war hart gesagt ein Abfallprodukt des Testprozesses und wurde nur aus reiner Menschenfreude bereitgestellt. Sie zu nutzen war meiner persönlichen Meinung nach nie eine gute Idee. Natürlich war es suboptimal. Wie es nun mit pkgng werden soll, weiß ich nicht. Aber da mit pkgng es nun endlich ein gutes binäres Paketmanagement geben wird, was zudem ein weitaus angenehmeres Repo-Format als nur dumme FTP-Verzeichnisse hat, würde es mich sehr wundern, wenn es nicht deutlich häufiger aktualisierte Paketen geben wird. Die bald kommende SVN-Umstellung der Ports bringt da auch aus Entwicklersicht neue Möglichkeiten, die man sicher einbinden könnte. Vielleicht kann das jemand anders mehr zu sagen. Zumindest ist das pkgng-Beta-Repo für 9.0/amd64 vom 14. Mai. Das 9.0-i386 pkgng-Beta-Repo sogar vom 6. Juni. Beides also nicht so alt. :)
 
pbi's sind echt cool, wenn es um Abhängigkeiten geht. Dafür schleppt aber jede pbi auch sämtlich notwendige Libraries mit, um auch sicherzustellen, daß es keine Komplikationen gibt. Dies wird/ist zwar schon soweit optimiert, daß schon vorhandene libs nicht nochmal installiert werden.

Daher sind pbi-Dateien in der Regel auch recht große Klopper. PBIs hab ich allerdings nur unter PCBSD ausgetestet, was unter FreeBSD ja auch funktionieren sollte.

Ich hab mal auf dem Schleppi pkgng getestet und bislang sieht das schon mal ganz nett aus.
 
Zumindest ist das pkgng-Beta-Repo für 9.0/amd64 vom 14. Mai. Das 9.0-i386 pkgng-Beta-Repo sogar vom 6. Juni. Beides also nicht so alt. :)

Wo findet man die URL dafür? Die im Text angegebene Adresse "etoilebsd.net" scheint nicht zu funktionieren?
Wenn die stable-packages also nur "Abfall" sind, wäre es dann nicht möglich, auf dem Forenserver hier zumindest für die gängisten ports stable-packages zur Verfügung zu stellen?
 
Zurück
Oben