Subject: Re: When has a binary package changed?
To: None <firstname.lastname@example.org>
From: Todd Vierling <email@example.com>
Date: 11/17/2005 12:23:16
On Thu, 17 Nov 2005, firstname.lastname@example.org wrote:
> > In which cases do we consider a binary package to be changed?
> When the content or the behaviour of the binary package changed,
> the revision should be bumped. This includes the requirement that a
> binary package could be build before the change, or at least installed.
I would like to take it a slight step further. Binary packages cannot
necessarily be built if the PLIST is wrong, but the package can still be
installed and registered (and thus be part of a DEPENDS) if built from
source. This is a special, but not uncommon, case.
I think the definition can be made a little more general, while preserving
the intent of "don't bump it if you only made a platform build", by
rewording this as:
PKGREVISION should be bumped when a package changes in a way that affects
any installed file or OS-level change on any platform, where the package
was previously installable from source on that platform; and when criteria
for runtime dependencies change for dependents of that package.
I'm very careful not even to mention binary packages. Binpkgs make changes
as a proper subset of the changes that happen when "make install" is done
from source. So, the better superset to examine for the PKGREVISION
criterion is "make install", not a binpkg.
Some clarifying examples for this definition follow, which are my opinions
(and the rules I've lived by), but may be used for codifying a set of rules.
I have included a few important out-clauses below to cover our infrequent
pkgsrc infrastructure changes.
* Changes to installed files include file contents and filesystem
attributes (owner/mode), even if the file is autogenerated by a script
and therefore not recorded in the PLIST. If the installation and/or
deinstallation process or script is changed in a way that is
functionally identical to previous installations, a PKGREVISION bump is
* OS-level changes are scripts or @[un]exec directives that affect files
and resources not controlled by pkgsrc. For instance, /etc/shells is
commonly modified by shell packages; and adding a user (or changing the
default username of an added user) in a package changes the system user
* Dependency changes occur when a DEPENDS changes in a package, or a
BUILDLINK_DEPENDS or BUILDLINK_RECOMMENDED changes in a buildlink3 file
directly included by a package. Indirect buildlink3 inclusions are not
covered, as they do not affect direct dependency information; and a bump
is also not required if a BUILDLINK_DEPENDS is bumped such that it is
still "less" than an also-present BUILDLINK_RECOMMENDED.
* Infrastructure changes that affect packages in any of these ways also
require bumps unless the cost of finding or bumping affected packages is
considered too high versus the installed userbase. For instance, the
libtool shared library name change in 2004 did warrant a bump (via
BUILDLINK_RECOMMENDED changes, which provided a user-specifiable
workaround) -- however, no bump was done for a change to libtool
affecting a hard-to-identify subset of shared libraries on Interix only.
-- Todd Vierling <email@example.com> <firstname.lastname@example.org> <email@example.com>