Subject: Re: RFC: recommended dependencies (diffs attached)
To: Rene Hexel <rh@netbsd.org>
From: Thomas Klausner <wiz@NetBSD.org>
List: tech-pkg
Date: 01/08/2004 17:24:02
On Fri, Jan 09, 2004 at 12:26:24AM +1000, Rene Hexel wrote:
> >> For example, when libgnome got updated to 2.4.0 the
> >>API was changed and older gnome2 packages would not
> >>build against the new version of libgnome
> >
> >That doesn't have to do anything with the BUILDLINK_DEPENDS,
> >since they only work the other way round.
>
> Huh?
I meant: Currently we only support applications that need an older
library than the one currently in pkgsrc by reimporting an older
release under a different name.
> > So it is only changed if _all_ dependent packages need
> >a newer version?
>
> Well, I'd replace all by "a majority of", but yes,
> that's the idea.
Ok, but we should make tools to find out when such a time
comes for those that don't switch all at once.
And we should make clear that older libraries than the one
currently in pkgsrc are _not supported_.
> For security updates we have both 'audit-packages' and
> RECOMMENDED. I don't think we should enforce updates if
> people choose to ignore warnings. For security updates,
> they would get two warnings, one from audit-packages and
> one from IGNORE_RECOMMENDED.
Yeah, but the second is only at install time, and only if
they install a package that depends on it. So we should make it
even more recommended to have audit-packages installed.
Perhaps even mandatory?
> I don't think additionally overloading dependencies
> with all of these roles is a good idea. Moreover (to
> repeat myself here), the current practice does not
> accomplish this either if users are forced into using
> unsafe practices such as inconsistent pkgsrc updates
> and/or 'make replace', and the like.
IMHO users are not _forced_ to do this :)
Anyway, we discussed this long enough already...
> People can make a conscious decision about not
> unnecessarily rebuilding huge parts of pkgsrc and
> when they do so, they get a warning that their
> binary packages may be incompatible with binary
> packages built against recommended prerequisites.
Which remindes me: The bulk build code should report failure if
it finds the variable set.
Also, if the recommended version is overridden, that should be
marked in the binary package too, perhaps as a BUILD_DEF; and
pkg_add should warn when it finds it.
This might actually work ;)
But please handle all corner cases we could find so far
before committing it.
Thomas