On 08/01/2004, at 11:40 PM, Thomas Klausner wrote:

> On Thu, Jan 08, 2004 at 11:08:47PM +1000, Rene Hexel wrote:
>>   Only if there is a real dependency change.  I.e., if
>> there is a user-visible change that only allows packages
>> to compile against one version of a package or another,
>> but not both.
>
> "Real dependency change" is exactly what I wanted explained.

   "I.e., if there is a user-visible change that only allows
packages to compile against one version of a package or
another, but not both."

>>   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?

   If I set BUILDLINK_DEPENDS.libgnome?= libgnome>=2.4.0
in buildlink2.mk of libgnome, then all dependent packages
will require at least 2.4.0 (unless they specifically
override this).

>> and vice versa.
>
> So the only case is when a package needs at least version x.y of
> the package?

   Yes, that's what we used dependencies for all along.

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

>  Otherwise we could just add
> 	BUILDLINK_DEPENDS.gnome-libs=gnome-libs>=2.4.0
> in the package that needs the newer version.

   Exactly.

> In case of security updates I guess you only set the recommended
> version higher and let the users of the override take care of
> themselves, right?

   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.

> How do you suggest a user finds out if he has non-recommended
> versions of packages installed?

   Careful here.  You can find out that you have outdated
versions of packages installed exactly the same way you
can find that out now.

   For security updates, there is 'audit-packages'.

   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.

   So where is the harm?  The default behaviour is
exactly the same as the one we have now.  Except
that we have additional information we can utilise.

   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.

   We have made a similar decision with
NO_{BIN,SRC}_ON_{FTP,CDROM} -- I don't see why
we shouldn't go down the same track here.

   Cheers
       ,
    Rene