[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [qubes-devel] Re: DNF for Debian



* 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

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.


>> 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.

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.



Mihai

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: