On Mon, 31 Jan 2005, Todd Vierling wrote:

> On Sun, 30 Jan 2005, Frederick Bruckman wrote:
>
>>> If the @blddep is not there (maybe because it was rm'd for sekurity
>>> reasons) and an updated @dep is available, that can be used just fine.
>>
>> How could you know that the ABI of the @blddep library didn't change?
>
> Because we're supposed to bump the BUILDLINK_RECOMMENDED if it does, and the
> bulk build should rebuild it.  This doesn't help binary packages much, but
> until we have a soname-based provides/requires type of thing, it's the best
> we can do.

And how would bumping the <anything> in pkgsrc affect the *existing* 
binary packages? This is the "open-ended dependencies" problem, again.

This discussion *is* about binary packages, nothing else.  I have 
proposed no changes to "pkgsrc". The problem, again, is that removing 
packages from the collection on the server for security aspersions 
breaks other packages, which are left on the server for some victim 
to attempt to install.

> Please *don't* remove anything based solely on @blddep.  That obviates the
> whole point of dewey dependencies.

I only said that would be the easiest way, not the best.  It would 
still be an improvement over the existing state of affairs, which 
leaves many broken packages on the server.  At least, you could see 
that they were missing without having to attempt to install them. It 
would remove no package that isn't already non-installable.

What do you think of my second idea, to move them to purgatory until 
some committer verifies that their requirement is, indeed, fulfilled 
by a newer package?


Frederick