| 1 |
El jue, 07-06-2012 a las 18:40 +0100, Ciaran McCreesh escribió: |
| 2 |
> On Thu, 07 Jun 2012 09:43:32 -0700 |
| 3 |
> Zac Medico <zmedico@g.o> wrote: |
| 4 |
> > I can imagine that ABI_SLOT operator deps will be a lot more popular |
| 5 |
> > than SLOT operator deps, since ABI_SLOT operator deps will accommodate |
| 6 |
> > the common practice of allowing ABI changes within a particular SLOT. |
| 7 |
> |
| 8 |
> You're missing out on a brilliant opportunity to encourage developers |
| 9 |
> put in a bit more work to save users a huge amount of pain here. |
| 10 |
> |
| 11 |
|
| 12 |
Won't be possible to encourage developers to make that "bit" more work |
| 13 |
when that work is not so "bit". Of course, I understand there are |
| 14 |
probably some valid cases when situation can (and should) be improved, |
| 15 |
but I still fail to see the advantage of allowing parallel installation |
| 16 |
for glib, xorg-server... taking care their reverse dependencies simply |
| 17 |
need a rebuild to work with latest ABIs and, then, users should anyway |
| 18 |
need to remove that old slots once reverse deps are rebuilt against |
| 19 |
latest slot as we wouldn't support setups where people is lazy to |
| 20 |
rebuild and have, for example, x11 drivers built against |
| 21 |
xorg-server-1.9.5-r1 even having 1.11.2-r2 installed in parallel. |
Archives