On Thu, 17 Nov 2005, joerg@britannica.bec.de 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
    not required.

  * 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
    database.

  * 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 <tv@duh.org> <tv@pobox.com> <todd@vierling.name>