Subject: Re: identify packages that were custom built?
To: NetBSD Packages Technical Discussion List <tech-pkg@NetBSD.org>
From: Marc Espie <firstname.lastname@example.org>
Date: 09/20/2007 10:38:40
On Thu, Sep 20, 2007 at 07:58:03AM +1000, Malcolm Herbert wrote:
> How would the proposed solutions catch the cases where the default
> options change during the life of a built package? I would suggest
> that if the options for a package build are saved, so should the
> defaults at the time ... that way you're covered even when the pkgsrc
> tree is updated.
We do have something like this in OpenBSD, with a few differences, but
yes, you've hit on some of the problems.
- we store non standard configure options as FLAVORS. And the package
ends up having them stored in a normalized order. In fact, we encode
it as part of the pkgpath this was built from, like this:
- a package can store supplementary pkgpath, which correspond to the way
things were built in the past, so that upgrade can proceed correctly.
- beware of development branches. We have both mutt/stable and mutt/snapshot,
and it would be considered ill-form for a package update to switch from
stable to snapshot... We deal with this simply (distinct pkgpath).
- a few options DO NOT make it into the pkgpath. We have a distinction
between flavors and pseudo-flavors (these are the options which do not
affect the package being built, but rather have an influence on other
aspects of package building. Granted, those happen mostly because of
multi-packages changes, something I don't remember netbsd having).
Even though options and paths may be the same, you can still end up
having to update a package because the dependencies
it used for building were updated, but I believe you already know that.