Hi, 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 packages… 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 PKG_OPTIONS.courier-authlib+=pam, 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. Thoughts? Re, /P
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail