eopkg: Add unified eopkg py3 package

[ermo]

trafficstars

Summary

NB: You may need to run sudo /usr/bin/eopkg update-repo --force && sudo /usr/bin/eopkg rdb to refresh the pisi py2 package database when migrating away from this package to old pisi py2.

This package would replace:

• The existing pure-python3 eopkg4 draft PR from Fabio
• python-eopkg (from Joey), which contains only the eopkg4 pure python libraries
• eopkg4-bin (from Hans), which is the currently in-testing method for getting python3-based eopkg4 code + PackageKit code onto Staff systems.

Hence, this package contains both the python library code, the pure python3 executables, the nuitka'd eopkg4.bin standalone executable, and the nuitka'd eopkgBackend.bin PK backend.

Like the just landed ypkg change, this package would enable like-for-like comparison between the pure .py versions and nuitka'd version and would control which versions are enabled on user systems via symlinks as a packaging operation.

The resulting benefit to Solus is that we don't have to bump two or three different packages each time we make a change, but have it all consolidated in one place.

Note that the eopkg py2 implementation we currently use is called pisi, hence the suggestion by Joey to call this one eopkg.

Test Plan

Built eopkg and tested using eopkg4-bin to install and remove packages.

Checklist

• [x] Package was built and tested against unstable

[joebonrichie]

You could possibly use a caret for the eopkg-python pkg like so

patterns :
    - ^python-eopkg :
         - /a/list/of/paths

That why it would match our existing naming convention for python pkgs and we wouldn't have to deprecate the existing python-eopkg pkg, just move it's source origin. To accommodate that the initial rel num would need to be 2 or we pull the existing python-eopkg pkg from ferryd first before landing this.

[ermo]

You could possibly use a caret for the eopkg-python pkg like so

patterns :
    - ^python-eopkg :
         - /a/list/of/paths

That why it would match our existing naming convention for python pkgs and we wouldn't have to deprecate the existing python-eopkg pkg, just move it's source origin. To accommodate that the initial rel num would need to be 2 or we pull the existing python-eopkg pkg from ferryd first before landing this.

This suggestion (with initial relnum = 2) has now been force-pushed to this branch.

It was tested against an unmodified ypkg build (v31-r182) and was found to work with the existing python-eopkg builddep specification in the ypkg package.yml as expected.

NB: The CI check failing is expected, as we're bumping the relno to 2 to be able to supersede installed stand-alone python-eopkg packages.

[ermo]

Force pushed with a bump to release: 3 to ensure that it replaces the existing python-eopkg (currently release: 2) if it gets merged.

[ermo]

Force-pushed with latest PackageKit eopkg python backend commit.

[ermo]

Need to figure out a solution for which package owns the /usr/share stuff in general, so re-marking as draft.

[ermo]

@sheepman4267 I'd like for you to commandeer this and get it in ASAP. I'm tired of the (IMO poor) dual package solution we currently have.

[sheepman4267]

@sheepman4267 I'd like for you to commandeer this and get it in ASAP. I'm tired of the (IMO poor) dual package solution we currently have.

I'll do this when I get a minute.