1 |
On Thu, Jun 07, 2012 at 08:15:28PM +0100, Ciaran McCreesh wrote: |
2 |
> -----BEGIN PGP SIGNED MESSAGE----- |
3 |
> Hash: SHA1 |
4 |
> |
5 |
> On Thu, 07 Jun 2012 15:14:03 -0400 |
6 |
> Ian Stakenvicius <axs@g.o> wrote: |
7 |
> > How is the case of something like libpng going to be handled, where we |
8 |
> > only support one API (and so only one SLOT)? Either in the proposed |
9 |
> > ABI_SLOT thing or when using slot operators? |
10 |
> |
11 |
> Ideally, by you putting in the work and supporting more than one API, |
12 |
> since doing so vastly improves the user experience. |
13 |
> |
14 |
> Failing that, SLOT plus blockers. Then if it turns out that really |
15 |
> doesn't work (and it's not just developers being utterly lazy), either |
16 |
> ABI_SLOT or parts in a future EAPI. |
17 |
|
18 |
SLOT + blockers only works for API breakages; for instances where API |
19 |
is the same but the ABI has shifted (a lib function switching from |
20 |
taking a short switching to a long for example), the scheme doesn't |
21 |
work and rebuilding is what's required. |
22 |
|
23 |
Thing is, the API breakage bit we already have sorted; point of this |
24 |
whole discussion is dealing w/ the latter scenario, which slot + |
25 |
blockers *doesn't* address; not unless your proposal is the |
26 |
clusterfuck notion of modifying the ebuild providing the lib, |
27 |
and sticking a shite ton of blockers for every known consumer. That |
28 |
approach is wrong on multiple levels to say the least. |
29 |
|
30 |
|
31 |
> > For the slot-operator case, will every consumer of libpng be forced to |
32 |
> > change their dep to libpng:= to ensure they get rebuilt when libpng |
33 |
> > bumps from 1.5 to 1.6?? |
34 |
> |
35 |
> Every consumer of libpng that wants to improve from the current |
36 |
> situation, yes. |
37 |
|
38 |
Just going to point something out here; you've spent a lot of time |
39 |
stating "Someone else has to go sort these problems out"- problems |
40 |
that in many cases are decades old. You want to enforce this hard |
41 |
line, you do the work. |
42 |
|
43 |
Reminder: Ebuilds sole purpose are to make integrators jobs easier. |
44 |
Not to enforce the views of EAPI authors, but to enable people to get |
45 |
shit done. |
46 |
|
47 |
ABI_SLOT should *not* be used all over the place; it's basically a |
48 |
corner case variable that allows integrators to work around known |
49 |
cranky upstreams, or generally thorny ass problems. Aka, scenarios |
50 |
where the slotting solution doesn't fit. |
51 |
|
52 |
Unless ciaran's plan is to step up and fix all of these offending |
53 |
scenarios (and keep doing so), ABI_SLOT should be landed at the same |
54 |
time as SLOT operators. We already know it has uses, and when it |
55 |
*occurs*, it's painful to deal with it- specifically at the user |
56 |
level. Provide the PM the neccessary data, and it can lessen that |
57 |
pain. |
58 |
|
59 |
~harring |