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 <a...@gentoo.org> 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
