On 11/27/19 9:31 AM, Georg wrote:

Hi list,

with the deprecation of Python2 ahead lots of packages currently built as split packages for py2/py3 will have to transition to non-split packages building only the py3 version, but this is not the only scenario when this could be needed. What is the correct workflow for this? It might depend on whether the pkgbase is the py2 vs py3 package vs another name (all cases exist).

I'm not sure I understand the question.

A PKGBUILD with a split package_*() and multiple pkgnames is just a way to build multiple packages from one PKGBUILD. The resulting packages aren't inherently tied together, and in fact, pacman -S doesn't even know that they came from the same PKGBUILD. (Although libalpm does record the original pkgbase, pacman doesn't use this information IIRC.)

You might need a transition if one resulting package takes over the conceptual purpose of multiple packages from a previous revision. For example:

https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/pygo...

The legacy pygobject 2.x bindings were in a split package, python-pygobject2 python2-pygobject2 and pygobject2-devel with common files. But python-pygobject2 was totally broken, so we removed the python3 support. It's a simple "remove the split package, no replacements, no transitions, no nothing, it is just gone".

And then there was only python2-pygobject2 and pygobject2-devel. Since only one package needed those development headers, the two split packages could be combined into one. This does need a "transition", simply because the old version of pygobject2-devel has *conflicting files* with the new version of python2-pygobject2.

The transition was very simple, and it is the same transition if we provided a package called "compton" and it died upstream and was replaced by a new package called "picom". The transition has *nothing* to do with the PKGBUILD that it came from, only the fact that one package deprecates another.

- picom PKGBUILD:

provides=(compton) conflicts=(compton) replaces=(compton)

- pygobject2 PKGBUILD:

provides=("pygobject2-devel=$pkgver-$pkgrel") conflicts=('pygobject2-devel') replaces=('pygobject2-devel<=2.28.7-3')

Now, python2-pygobject2 is the only package, and to ensure that no one is permitted to have the pygobject2-devel package, python2-pygobject2 will provide it (ensuring dependencies on the legacy pygobject2-devel package are still met), conflict it (to force pacman to uninstall pygobject2-devel while upgrading), and replace it (to make pacman install python2-pygobject2 if you only had pygobject2-devel installed).

...

All these things apply regardless of whether the package was built from one PKGBUILD or two PKGBUILDs.

...

For python2 packages which are dropped from the repos, pacman only knows that the package is gone, and if you want to get it, you'll need to install it from the AUR. AUR maintainers may take inspiration for writing a new PKGBUILD, based on previous revisions of the one in the official repos, but that is all.