On Sun, 7 Nov 2004, Jaromir Dolecek wrote:

> > Yes.  This will mean that many folks won't get necessary security or other
> > important fixes on a timely basis.
>
> Arguably the software packaging system should not force users
> to upgrade their systems unnecessarily.

To which I fully agree.

However, there are very good reasons to require updating to a newer version
of a package if the user does not explicitly request to override it.
Security fixes are only one such reason; ABI incompatibilities are another,
and there's also bugfixes which address frequent user complaints or major
functionality breakage.

(BTW, while I do think that audit-packages is a necessary tool, the default
behavior of pkgssrc should *not* be to allow vulnerable packages to remain
installed if an update is requested.)

> The way we currently do buildlink depends is not good, they are
> bumped way too often,

Yes, they are, and again I agree on this concept.

The pkgsrc leadership should confer separately about a better policy for
BUILDLINK_DEPENDS and BUILDLINK_RECOMMENDED, declare it, and put it into
force to address this without diluting the purpose of RECOMMENDED.  As I've
said before, the following sounds like a very sane way to do it:

* BUILDLINK_DEPENDS reflects the absolute minimum "compatible" (at source
  level) version of the package to make dependents work.  The version in
  BUILDLINK_DEPENDS may or may not be ABI compatible with the "current"
  version of the package.

* BUILDLINK_RECOMMENDED reflects the minimum feasible, ABI compatible
  version of the package to be used in production environments.

  The only absolute constraint here triggering BUILDLINK_RECOMMENDED bumps
  is "ABI compatible", in that shlib major bumps (or other ABI
  incompatibilities) occur in the new version.  (This is absolutely critical
  for binary packages, but nearly as important for people building from
  source with various tools like pkg_hack or pkg_tarup.)

  In practice, this should NOT be bumped often, only upon ABI changes and/or
  carefully thought out choices about what is "fixed" in the new version
  (security, or major breakage).

> mostly just because single or just couple other packages require the new
> version.

Actually, there's a mechanism for just this purpose:  in the dependent
requiring a newer version, add to the BUILDLINK_DEPENDS.dependency variable
(with +=).  The higher-numbered dewey DEPENDS will win automatically
(whether the special one used in the dependent, or the one in the
dependency's bl3 file).

This is used in several places already, and should be encouraged (again,
perhaps something that needs formal codification by pkgsrc leadership) in
preference to bumping BUILDLINK_{DEPENDS,RECOMMENDED}.

> Anyway, back to RECOMMENDED - IMHO it should be opt-in.

No.  I again point out that it is of near zero value if it is off by
default.  Who would *enable* it in that case?  The whole point of
RECOMMENDED is to have a default newer-than-DEPENDS dependency BY DEFAULT,
allowing older versions only if the user takes special action to use them
instead.

Please review my suggestions wrt BUILDLINK_RECOMMENDED above, and in that
context, would you still consider this necessary to turn off by default?

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com>