[arch-dev-public] [arch-dev] Packaging inconsistencies of python modules

[Ray Rashif]

At first I didn't want to bring this up openly, as a precaution, but I
suppose it's alright.

On 5 April 2011 21:37, Dan McGee <dpmcgee at gmail.com> wrote:
> As Stéphane said, we have a problem here in those periods where a
> package becomes python 3 compatible, is split, but all packages
> depending on it are not rebuilt. Even this would not satisfy all our
> issues as many packages optdepend on these modules, and/or are just
> installed for someone's script X on their system that we aren't
> tracking deps for in the first place. These two reasons make the
> rename/rebuild idea not fully work, in my opinion.

Yes, true. We're doing this now:

python-foo -> python2-foo:
  conflicts=('python-foo<$newver')

python-foo *new*:
  provides=('python3-foo')

python3-foo -> python-foo:
  provides=('python3-foo')
  conflicts=('python3-foo')
  replaces=('python3-foo')

If things depend on the old 'python-foo', we rebuild them. If things
like make/opt depends are missed, people file bug reports, and we
ammend as appropriate.

Two key points:

(1) The breakage comes only when doing an upgrade, and the new
'python-foo' gets into the system not because of any renaming or
replacement, but because $currentver < $newver.

(2) Thus, the uninformed user (which is basically all of us at such a
point in time) gets an unwanted "update"; a python2 module gets
replaced by a python3 one.

However, this is "solved" by (re)installing the renamed package.
Optionally, by this convention, all such updates could warrant an
announcement each. Alternatively, prepare a group of such updates, and
post an announcement to inform users to upgrade the system with their
important packages specified in the list:

pacman -Syu python2-importantfoo python2-importantbar

Granted, that is very troublesome. Someone (or many) will not be
prepared. But it's the only way. If we now begin to introduce
python3-* stuff to work around the problem, it all really becomes a
mess.

We can, of course, initiate another move to have 'python3' instead of
'python' (I don't think this one would be difficult since we already
do provision there).

Or, well, following NumPy, leave 'python' as-is and make it a
convention for modules to use a 'python3-' prefix, even though it
wouldn't look consistent with the python package. I have no doubt
people will start asking why we don't just rename 'python' to
'python3', then.


--
GPG/PGP ID: 8AADBB10