tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Howto make upgrading binary packages (PKG_OPTION) safe?


We have a few NetBSD machines running, serving multiple services, and nearly 
100% of all the services are from pkgsrc software... 

Having this scenario in mind, makes it convenient to use tools like pkgin to do 
binary package updates. However, it's not 100% smooth to update all of the 

One problem with pkgsrc binary packages are that they only come with a 
predefined default of features enabled.
Some service we have require modifications (eg. more PKG_OPTIONS).
I guess it's okay to recompile those few packages as long as pkgsrc doesn't 
have support for multiple package options now. 

But an annoying problem is that, for instance, pkgin doesn't have a mechanism 
of recognising that the package its about to upgrade lacks PKG_OPTIONS compared 
to the currently installed package.
As an example, I have courier-authlib installed and compiled with 
which is described in the package 
/var/db/pkg/courier-authlib-0.64.0nb5/+BUILD_INFO as PKG_OPTIONS=bdb pam

First, I don't know if this "problem" not to recognise differences should be 
classed as a pkgin specific problem, or general pkgsrc problem? (I'm uncertain 
if there are other pkg tools that handles binary updates/upgrades as well)

Secondly, how should this be solved in the best way?
Should we make sure that the pkg tools that performs the upgrade should solve 
this issue by themselves, like in the pkgin case, that pkgin should compare the 
PKG_OPTION field of every package that it targeted for upgrade against the 
newer downloaded version of each package, before it starts upgrading them?
Or could we start by inserting an extra variable into +BUILD_INFO (for instance 
PKG_SUGGESTED_OPTIONS) that gives the default built PKG_OPTIONs, so all pkg 
tools simply can see that this package was compiled with custom PKG_OPTIONs. 
Then the pkg tools can simply compare PKG_OPTION with PKG_SUGGESTED_OPTIONS and 
warn me if I'm about to upgrade the package to a newer version with 
non-matching PKG_OPTIONs.
Of course, PKG_SUGGESTED_OPTIONS could change over time, but it's not that 
common that it changes…
To be fully covered, the pkg tools needs to compare both the old and new 
packages PKG_OPTIONs to see that they match.   



Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Home | Main Index | Thread Index | Old Index