[gentoo-python] Fixing python-exec slotting issue

[gentoo-python] Fixing python-exec slotting issue

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2576 bytes --]

Hello,

I need someone to confirm my thoughts.

Packages built some time ago have 'dev-python/python-exec' (without any
slot) in deps. This means that portage will be happy to remove
python-exec:0 (and break those packages) as soon as python-exec:2 is
installed.

Modern Python packages have := dep on it. Those built with
python-exec:2 around (and therefore using it) will have the dep
converted to python-exec:2, and those with :0 will have :0. So those
are fine.

Now, we don't have a proper way of updating deps of the old packages,
and portage's --dynamic-deps doesn't seem to handle it. We can either:

a) tell users to hack their vdb and fix deps therein,

b) tell users to rebuild all python stuff before running --depclean,

c) move packages around a bit and possibly fix it.

Since c) should work without requiring users to read news and hack or
rebuild stuff, I think that'd be the best route. However, I'd need
someone to confirm that my thoughts are correct.


The idea would be to move python-exec2 to a separate package use that
package in the eclass deps. That is:

a) dev-python/python-exec2 would have two slots:

- 2*:0 that would contain python-exec2 itself,

- 0:compat that would pull in python-exec:0.

b) dev-python/python-exec would have two slots:

- 4.*:0 that would contain the original python-exec,

- 3:2 that would pull in python-exec:2.

c) the eclass would have the following dep:

  dev-python/python-exec2:=


Now, I think the following would happen:

a) 'dev-python/python-exec' deps would still be satisfied by any slot
of python-exec but...

b) @world upgrade will pull in highest PV with slot :0 for them, so
they won't get broken,

c) previously-built packages with 'python-exec:0' and
'python-exec:2' (due to := dep) will still pull in correct version of
python-exec (possibly through the compat version),

d) new packages will have 'dev-python/python-exec2:=' dep and therefore
use the new package.


Notes:

a) people who haven't installed python-exec:2 yet won't even use that
slot,

b) stable users will pull in python-exec2:compat virtual slot,

c) when python-exec2:0 goes stable, people will cleanly upgrade to it,

d) we will be able to lastrite dev-python/python-exec and remove
dev-python/python-exec2:compat afterwards. In case people still use it,
PM will simply keep the old versions in vardb,

e) python-exec2:0 will have a blocker for <python-exec-3:2 to ensure
clean switch.

Am I missing something?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-python] Fixing python-exec slotting issue

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 745 bytes --]

Dnia 2013-10-02, o godz. 13:30:51
Michał Górny <mgorny@gentoo.org> napisał(a):

> Now, we don't have a proper way of updating deps of the old packages,
> and portage's --dynamic-deps doesn't seem to handle it. We can either:
> 
> a) tell users to hack their vdb and fix deps therein,

Another possible solution popped up in #gentoo-python.

We could make python-exec:2 ebuild run a quick vardb fixup.

find -name '*DEPEND' -exec \
  sed -i -e 's@dev-python/python-exec\[@dev-python/python-exec:0[@' {} +

While ugly, it should be fairly safe and easy to do. And I think that
we can currently rely on vdb internals like this since other ebuilds,
eclasses and software does that as well.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]