Subject: Re: inflation of PKGREVISION bumps [was Re: CVS commit: pkgsrc]
To: None <email@example.com>
From: Rene Hexel <firstname.lastname@example.org>
Date: 01/06/2004 10:29:12
On 05/01/2004, at 6:51 PM, Thomas Klausner wrote:
> Yeah, but that's the problem: How do you force that this
> 'as long as' is true? Currently there is only one way, and
> that is by bumping the DEPENDS.
I don't. To a degree you have to trust developers to
DTRT. I don't think forcing everyone to update everything
just because developers who upload binary packages are
supposed to do that from a consistent, up to date set of
packages is the right way to go.
> And I don't think anything except forcing it will really work
You can't enforce everything. What if people use
non-standard settings in their mk.conf? What if people
use 'make replace', 'pkg_add -f', etc.?
In fact, the only think bumping PKGREVISIONs and DEPENDs
enforces is that people either put up with endless
recompilation orgies or update only parts of their
pkgsrc tree to get some work done. IMHO the danger then
up upload packages that were created from an inconsistent
pkgsrc tree is much greater this way than without the
Also, while I agree that in theory, enforcing a stable,
consistent package system is a good thing, in practice,
this is not the case. Pkgsrc is hardly ever in a state
where everything compiles.
So for the end user, the current situation is a
difficult as well. Updates that require the whole
system to be recompiled very often push a perfectly
working system into an unusable state, because some
intermediate package no longer compiles. Forcing
people to use 'make replace' and the like to avoid
these kinds of problems is IMHO a greater evil than
allowing packages that are, in fact, compatible with
each other to install together.
I agree that it is important to have consistent
binary packages on ftp.netbsd.org. But to enforce
that at the expense of developers and end users
who compile their packages from source is not the
right thing to do.
If we really want to go down that (enforcement) road,
then we need something that is different from abusing
PKGREVISION/DEPENDS. Maybe a RECOMMENDED_REVISION
in buildlink*.mk that produces a warning that a package
is not suitable for uploading (similar to NO_BIN_ON_FTP
maybe). That should be fairly easy to implement (and
I'd be happy to have a stab at that).
> Btw, I'm having second thoughts on your INCOMPATIBLE -- if
> we allow that, the 'as long as' can't be forced at all, can it?
INCOMPATIBLE is orthogonal to the mechanisms that we
have been using in the past. It's just an additional
mechanism that can be used to track and record
incompatible ABIs so that binary packages cannot be
installed against incompatible prerequisites.