Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Brian Harring]

On Thu, Jun 07, 2012 at 08:15:28PM +0100, Ciaran McCreesh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thu, 07 Jun 2012 15:14:03 -0400
> Ian Stakenvicius <axs@g.o> wrote:
> > How is the case of something like libpng going to be handled, where we
> > only support one API (and so only one SLOT)?  Either in the proposed
> > ABI_SLOT thing or when using slot operators?
>
> Ideally, by you putting in the work and supporting more than one API,
> since doing so vastly improves the user experience.
>
> Failing that, SLOT plus blockers. Then if it turns out that really
> doesn't work (and it's not just developers being utterly lazy), either
> ABI_SLOT or parts in a future EAPI.

SLOT + blockers only works for API breakages; for instances where API 
is the same but the ABI has shifted (a lib function switching from 
taking a short switching to a long for example), the scheme doesn't 
work and rebuilding is what's required.

Thing is, the API breakage bit we already have sorted; point of this 
whole discussion is dealing w/ the latter scenario, which slot + 
blockers *doesn't* address; not unless your proposal is the 
clusterfuck notion of modifying the ebuild providing the lib, 
and sticking a shite ton of blockers for every known consumer.  That 
approach is wrong on multiple levels to say the least.


> > For the slot-operator case, will every consumer of libpng be forced to
> > change their dep to libpng:= to ensure they get rebuilt when libpng
> > bumps from 1.5 to 1.6??
>
> Every consumer of libpng that wants to improve from the current
> situation, yes.

Just going to point something out here; you've spent a lot of time 
stating "Someone else has to go sort these problems out"- problems 
that in many cases are decades old.  You want to enforce this hard 
line, you do the work.

Reminder: Ebuilds sole purpose are to make integrators jobs easier.  
Not to enforce the views of EAPI authors, but to enable people to get 
shit done.

ABI_SLOT should *not* be used all over the place; it's basically a 
corner case variable that allows integrators to work around known 
cranky upstreams, or generally thorny ass problems.  Aka, scenarios 
where the slotting solution doesn't fit.

Unless ciaran's plan is to step up and fix all of these offending 
scenarios (and keep doing so), ABI_SLOT should be landed at the same 
time as SLOT operators.  We already know it has uses, and when it 
*occurs*, it's painful to deal with it- specifically at the user 
level.  Provide the PM the neccessary data, and it can lessen that 
pain.

~harring