[aur-general] Transition from split package to unsplit package

[Eli Schwartz]

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/pygobject2&id=4cce72ee56cea6dcdb314a0a6c3066148390aaed

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.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20191127/60b62b4c/attachment.sig>