Peter, Mihai, On 2020-07-02 15:46, Mihai Moldovan wrote: > * On 7/2/20 2:27 PM, Peter Pentchev wrote: >> On Thu, Jul 02, 2020 at 10:34:19AM +0200, Frédéric Pierret wrote: >>> - modulemd1 >> >> Hmm, I have an ITP bug open for libmodulemd as part of my work on >> createrepo-c and my libmodulemd package is already in NEW :) >> https://ftp-master.debian.org/new.html Sorry I've missed it. I don't have the whole big picture of Debian packaging pipelines in mind yet. > That's fine. Note that you packaged libmodulemd 2.x, which is not what dnf > needs. I hence named it modulemd1. (Could have went for libmodulemd1 as well, > but that felt odd.) > > AFAIK, the last time I looked, dnf was only compatible with the older > libmodulemd 1.x version. Fedora has also two explicit versions for this: libmodulemd (2.X) and libmodulemd1 (1.X ...) and they keep maintaining both of them. >>> There is mostly one commit above the source of Mihai with "Uploaders"Frédéric Pierret <frederic.pierret@qubes-os.org> >>> field added. Lintian reports several things to improve but I would >>> like to have some feedback/help on making this moving forward from >>> Debian side first before doing any new moves. Also this set of >>> packages relies on libsolv but the patch set of Mihai has been >>> currently reverted >>> (https://salsa.debian.org/debian/libsolv/-/commit/730e23a04b397cd8d8d28c8081e5ade968e04176) >>> due to pending Debian strategy about global RPM integration. > > I'd welcome this a lot. The libsolv patch is really a big hack to make libsolv > aware of and compatible with (the changes in) Debian's rpm package. This change > breaks a lot of stuff, including mock. It's painful and the gain is > questionable. The initial idea was to discourage (and essentially make it > impossible) to install rpm packages system-wide. > > That's easily worked around, though, for anything that not uses a chroot, by > just setting %dbpath to the system location, so the whole benefit is > questionable. Worse, in chroot environments (which are typically used when > building software), all this is breaking down and getting a lot more complicated. FYI, at first from Qubes side, we target only the use of basic DNF workflows. Especially, being able to fetch and download RPM only. We don't plan to use mock inside Debian but that's ours need and maybe that's not sufficient for Debian? > IMHO, a discussion and move to remove that rpm patch was long overdue. > > >> BTW would some of these be better in the RPM packaging group? > > Probably all of them? But the RPM packaging group is kind of stale. I would be fine with it of course. > > Mihai > Thank you for your answers. Frédéric
Attachment:
signature.asc
Description: OpenPGP digital signature