Questions about pkgng

F

frijsdijk

Hi,

I'm currently testing ports-mgmt/pkg, and I think with a repository of your own, so ports can be compiled with your favorite options, is a pretty nice new software management tool for FreeBSD. Without your own repo however.. no so much yet. Let's hope that good repositories will appear soon!

My questions are:

1) Besides ports-mgmt/tinderbox en ports-mgmt/poudriere, are there any other package building tools available for making your own repo? ports-mgmt/poudriere seems to be my favorite over tinderbox by far.

2) Once we do the 'pkg2ng' procedure, and we add
Code: 
WITH_PKGNG=YES
to our /etc/make.conf, can we ALSO use the 'regular' ports to install third party software? (using either ports-mgmt/portmaster or ports-mgmt/portinstall)
 
1) ports-mgmt/poudriere is getting better all the time, stick with it if it works for you.

2) Once you have WITH_PKGNG in /etc/make.conf you can install ports the standard way by saying make install the port's directory and the built port will be registered as a PKGNG package. Tools that use the standard ports(7) API to build the ports will work the same, ports-mgmt/portmaster should have built-in support for PKGNG now.
 
One big advantage that ports-mgmt/poudriere has over others is that it does incremental builds. This roughly means that it can take the last build / package in the repository and patch the difference rather than re-building the whole thing from scratch. This saves time and provides less wear on your HDD.

Both ports-mgmt/portmaster and ports-mgmt/portupgrade are working fine with pkgng (they build and register packages correctly).

Once we do the 'pkg2ng' procedure
Click to expand...
Aaand there's the problem...

1. Any package you had built and is in your package collection prior to setting WITH_PKGNG=YES will no longer work. The reason is that pkgng keeps package info in an sqlite database, so packages adhering to pkgng format must start with headers for the sqlite entry (old format package builds do not have that). Conclusion: Do the switch after you have setup your build system because the old package collection will be worthless.
2. pkg2ng procedure has errors and can fail to correctly register your entire pkg collection into the sqlite database. This will leave you with a half-ass collection of registered packages, with a number of packages in "purgatory" (installed and working but not registered). Debugging this is very difficult because # portmaster --check-depends nor portupgrade fix tools are not supported under pkgng (the tools cannot fix anything in the sqlite database), while pkg its' self provides no tools for such a situation. There are a number of checks and "precautions" suggested to prevent such a problem but they seem like quite a pain-in-the-rear to me.
3. If you do get an incomplete database (due to erroneous pkg2ng conversion) of installed packages, your subsequent port update process will by definition also be incomplete. Both portmaster and portupgrade will now look in the new database being served by pkgng, so updates will search only ports/packages which successfully registered during the pkg2ng conversion. Any package which failed to register will be skipped over during update (this is what happened to me).
4. Solution: I think that the best transition is to:
* Setup poudriere[/FILE
* Obtain the list of all installed ports + packages
* Build the packages for all of the list under poudriere
* Remove all packages and re-install from the fresh repository.

Conclusion: Do not migrate until you have all of this sorted out in your head.
 
Worth to mention is that portmaster doesn't build with pkgng support by default.
Code: 
# cd /usr/ports/ports-mgmnt/portmaster
# make config
# make reinstall
 
I find this easier to navigate through:
Code: 
# cd /usr/ports
# make config -C ports-mgmnt/portmaster
# make reinstall -C ports-mgmnt/portmaster
 
You must log in or register to reply here.
Back
Top