Short version: I submitted python-soupsieve package for review [1], and I'd like to also build the python2 subpackage. python2-soupsieve will be used by calibre and python2-beautifulsoup4, which in turn is used by various other packages. I'm asking for an exception to allow this and other python2 dependencies of calibre to be added to Fedora.
Long version: so far soupsieve wasn't used by anything in the distro, but the latest version of beautifulsoup gained a dependency on soupsieve. In addition, latest version of calibre also did. Those updates [2, 3] are blocked by the availability of python2-soupsieve.
python2-beautifulsoup4 is in turn required by a bunch of other things:
$ dnf repoquery --qf '%{name}' --disablerepo=\* --enablerepo=rawhide{,-source} --whatrequires python2-beautifulsoup4 chromium mote packagedb-cli python-fmn-lib python-html5-parser python-webtest python2-fedora python2-fmn-lib python2-webtest
calibre port to python3 is progressing, but current state is not stable. Ideally, we should keep using the python2 version, and switch over to python3 when its ready. But it's hard to say when exactly this will happen. Calibre is a quickly moving project so leaving it without updates for months is not a good option.
@churchyard suggested one of the alternative following courses of action: 1. split bs4 into two packages, update py3, orphan py2
This doesn't help, because I want to update calibre to the latest version, which still requires bz4 and soupsieve.
That seems like a maintenance nightmare. Patching projects to make part of the functionality optional seems like a lot more work than keeping the python2 subpackages, and is likely to be much more fragile too.
All in all, adding the python2 subpackage seems like the best option to keep packages updated in Fedora and pave the way towards calibre-on-python3. Once calibre is switched over, and the other packages in the list above are updated or retired, python2-soupsieve and python2-beautifulsoup4 will be removed.
In addition, there are additional new dependencies of calibre: python2-css-parser [4]. They are necessary for newer calibre versions the same as python2-soupsieve. It is possible that some other packages will need to be added. They only make sense together.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1719008 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1667497#c13 [3] https://src.fedoraproject.org/rpms/python-beautifulsoup4/pull-request/3 [4] https://bugzilla.redhat.com/show_bug.cgi?id=1719395
+1 from me to get those python2 subpackages. We do not want to not update calibre because of that.
Normally I strongly dislike bundling, but I wonder if this is a case where it is reasonable to consider it. Would it be crazy to consider that as an alternative?
I'm not opposed to your proposal though, just wanted to throw another idea out there for consideration. Consider me a +1 to your proposal too.
Considering in all the other options, I can +1 this as well (even opposed to bundling).
Note that soupsieve has no new dependency.
As a side note, we really need to get rid of Python 2 in Fedora specific packages (mote, fmn, pkgdb, github2fedmsg...).
Bundling is not an attractive solution because (apart from all the other obvious reasons) we do want the python3 version of those packages in the longer term. So we'd have the same code in the same version in multiple locations: bundled python2 copy an unbundled python3 copy. It could be made to work, but it'd be ugly and complicated for no good reason.
It'd be great to have some feedback from the owners. I looked at packagedb-cli yesterday, and the upstream project is dead (archived on github). @pingou wrote that there are external users of pkgdb. It seems reasonable to assume that packagedb-cli might be used by some contributors, but we can't keep supporting them. Can we retire the package in rawhide now?
Similarly, fedmsg is going away, but it is still maintained, and there's a fedmsg→fedora-messaging bus. Should we retire it in rawhide now?
mote is in use. We should port it to python3. I see it also depends on fedmsg. I can help with porting to pytho3, but I'd need some confirmation from the project owners that the project is there to stay...
I create a PR for mote to update it a bit [1]. It still has the dependency on fedmsg, but it's just ~40 lines of code [2], so maybe someone could update it to use the new bus? @adamwill?
[1] https://github.com/fedora-infra/mote/pull/122 [2] https://github.com/keszybz/mote/blob/master/mote/fedmsg_consumer.py
On the specific case of packagedb-cli, the code is py3 compatible for a while, if someone is interested in keeping it, it could be switched to be py3 only by just adjusting the spec file.
Maybe I should just announce an intent to orphan.
Metadata Update from @churchyard: - Issue tagged with: meeting
* AGREED: python2 packaging exception for python2-soupsieve, python2-css-parser is approved (+7, 1, -0) (contyk, 15:50:22)
Metadata Update from @psabata: - Issue untagged with: meeting - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.