DNF for Debian

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

DNF for Debian

Mihai Moldovan
Hi


I've packaged DNF for Debian and would like to find someone to take over these
packages and maintain them as part of the distribution.

I'm not a DD and while I believe the packages to be of reasonable if not high
quality, I already have enough on my plate and know that I will not be able to
properly maintain them, keep up with upstream releases etc.
Point in case: while I did the original packaging more than a year, I only
updated this set of packages recently when they actually broke with newer Fedora
releases (i.e., they were too old to create newer Fedora changeroots when used
by mock).



== What is DNF? ==

For a long time, Fedora/RHEL/CentOS (and derivatives) used YUM as their default
package manager. DNF is a feature-rich YUM fork intended to replace it
eventually, using libsolv as its dependency solver, entered Fedora in version 18
as an option and has been its default package manager since version 22. RHEL 8,
based on Fedora 28, also already uses DNF as its default package manager.



== Why does Debian need DNF? ==

Debian already has packages for yum and mock. Building RPM packages on a Debian
system is a supported use case already utilized by a (probably rather small
amount) of users. That alone is normally not enough reason to introduce new
packages, but newer Fedora versions use features like boolean (or rich)
dependencies[0] that are plainly not supported by yum. Building such chroots
will flat out fail. DNF is now a hard dependency for supporting newer Fedora and
RHEL versions.

Without DNF, Debian would at some point lose the ability to be used a build host
for RPM packages.

Debian does NOT need DNF as an additional native package manager, but that
should be pretty clear. No sane user would (and should) try to mix dpkg/apt and
rpm/{yum,dnf} packages on a Debian system.



== Prerequisites ==

Most packages within unstable/sid are new enough.

The rpm source package needs a few rather trivial backports for new RPM tags -
submitted as https://bugs.debian.org/940114

The libsolv source package needs patches fixing its CMake integration, making it
usable with the "rpmdb-in-homedir" patch that is applied to Debian's rpm package
and enabling the COMPS feature - submitted as https://bugs.debian.org/889509

Eventually, I'd like Debian to completely drop the "rpmdb-in-homedir" patch
since it's causing more trouble than solving issues - a lengthy description of
why that is can be found in https://debugs.debian.org/794495 . While that is not
the case, we will have to patch libsolv to support that non-standard RPM behavior.



== Package List ==

=== libcomps 0.1.11-1 ===

Libcomps is library for structure-like manipulation of content in
comps XML files. Supports reading/writing XML files and structure
modifications.

Needed by: dnf


=== librepo 1.10.5-1 ===

A library providing C and Python (libcURL-like) APIs to
download repository metadata.

Needed by: libdnf


=== modulemd1 1.8.15-1 ===

A C library for manipulating module metadata files.

Needed by: libdnf, dnf


=== libdnf 0.35.3-1 ===

A library providing simplified C and Python APIs to libsolv.

Needed by: dnf


=== dnf 4.2.9-1 ===

Package manager forked from Yum, using libsolv as a dependency resolver.

Needed by: as explained above, also dnf-plugins-core


=== dnf-plugins-core 4.0.9-1 ===

This package enhances DNF with builddep, config-manager, copr, debug,
debuginfo-install, download, needs-restarting, repoclosure, repograph,
repomanage, reposync, changelog and repodiff commands.

Additionally provides generate_completion_cache passive plugin.

Needed by: mocks operation (builddep for instance) (not a proper dependency yet)



== Repository ==

Source and binaries (for unstable/sid, amd64) can be found at
https://packages.x2go.org/debian-test/pool/main/

If you want to test that, use something like

deb     http://packages.x2go.org/debian-test sid main
deb-src http://packages.x2go.org/debian-test sid main



== Personal Note ===

I've been using DNF for the past one-and-a-half years for building RPM packages
on a Debian stretch machine. The proposed packages contain a few patches needed
for stretch integration (and stretch also needs changes to
gobject-introspection, glib and util-linux for DNF to build and work correctly).
I didn't want to rip them out and they don't cause trouble on newer-than-stretch
systems since their effect is essentially deactivated there. They are, however,
marked with "stretch" in the description and dropping them should be very easy.

They seemed to be very usable and stable for my use case - building RPM packages
via mock.



Mihai



[0] Debian/dpkg/apt has already known one of these "boolean(/rich) dependencies"
for quite some time - OR dependencies. RPM adds further ones, like (A if B)
which pulls in package A if B is already installed on the user system while
installing the dependent package, (A if B else C), which is the but extended
with a ternary term and crazier ones like (A with B), which instructs the solver
to find ONE single package that fulfills both A and B. Confused? A and B need
not be actual packages, it's totally valid for them to be other expressions,
like fully virtual ones. RPM spec files can use any statement in Provides:
clauses - and those can either live in a specific namespace (e.g.,
"pkgconfig(rpm)", which looks for an "rpm" capability in the "pkgconfig"
namespace) or in the global namespace (e.g., "mta", as a virtual package
specification). Yes, it's complicated to understand and arguably error-prone
(for humans), but the usage of such expressions is abundant within the
repositories nowadays.


signature.asc (916 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DNF for Debian

Holger Levsen-2
Hi Mihai,

On Fri, Sep 13, 2019 at 05:36:55PM +0200, Mihai Moldovan wrote:
> I've packaged DNF

cool!

> for Debian and would like to find someone to take over these
> packages and maintain them as part of the distribution.
>
> I'm not a DD and while I believe the packages to be of reasonable if not high
> quality, I already have enough on my plate and know that I will not be able to
> properly maintain them, keep up with upstream releases etc.
> Point in case: while I did the original packaging more than a year, I only
> updated this set of packages recently when they actually broke with newer Fedora
> releases (i.e., they were too old to create newer Fedora changeroots when used
> by mock).
hm, I'd be willing to sponsor and mentor those uploads, but I cannot commit
to maintaining them as well. Is there anybody out there who would?

> == What is DNF? ==
[...]
> == Why does Debian need DNF? ==
[...]
> == Prerequisites ==
[...]
> == Package List ==
[...]
> == Repository ==
[...]

all very very nice! It would be a pity to have this rot, but then, without
maintenance it will anyway eventually...


--
cheers,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DNF for Debian

Thomas Goirand-3
In reply to this post by Mihai Moldovan
On 9/13/19 5:36 PM, Mihai Moldovan wrote:
> Hi
>
>
> I've packaged DNF for Debian and would like to find someone to take over these
> packages and maintain them as part of the distribution.

Nice ! Thanks for the work.

> [...]
> == Why does Debian need DNF? ==
>
> Debian already has packages for yum and mock. Building RPM packages on a Debian
> system is a supported use case already utilized by a (probably rather small
> amount) of users. That alone is normally not enough reason to introduce new
> packages, but newer Fedora versions use features like boolean (or rich)
> dependencies[0] that are plainly not supported by yum. Building such chroots
> will flat out fail. DNF is now a hard dependency for supporting newer Fedora and
> RHEL versions.
>
> Without DNF, Debian would at some point lose the ability to be used a build host
> for RPM packages.
>
> Debian does NOT need DNF as an additional native package manager, but that
> should be pretty clear. No sane user would (and should) try to mix dpkg/apt and
> rpm/{yum,dnf} packages on a Debian system.

I used to use yum for doing the equivalent of debootstrap, ie:
setting-up a CentOS chroot from a Debian host. This is why I maintained yum.

Can DNF be used for that as well?

> == Package List ==
> === libcomps 0.1.11-1 ===
> === librepo 1.10.5-1 ===
> === modulemd1 1.8.15-1 ===
> === libdnf 0.35.3-1 ===
> === dnf 4.2.9-1 ===
> === dnf-plugins-core 4.0.9-1 ===

All of these would nicely fit within the RPM team! Please request to be
a member, and I'll add you there:

https://salsa.debian.org/pkg-rpm-team

Then I probably take the time to sponsor it, or maybe other team members
can do too.

Cheers,

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

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

Unman
In reply to this post by Holger Levsen-2
On Sun, May 03, 2020 at 12:03:40PM +0000, Holger Levsen wrote:

> Hi Mihai,
>
> On Fri, Sep 13, 2019 at 05:36:55PM +0200, Mihai Moldovan wrote:
> > I've packaged DNF
>
> cool!
>
> > for Debian and would like to find someone to take over these
> > packages and maintain them as part of the distribution.
> >
> > I'm not a DD and while I believe the packages to be of reasonable if not high
> > quality, I already have enough on my plate and know that I will not be able to
> > properly maintain them, keep up with upstream releases etc.
> > Point in case: while I did the original packaging more than a year, I only
> > updated this set of packages recently when they actually broke with newer Fedora
> > releases (i.e., they were too old to create newer Fedora changeroots when used
> > by mock).
>
> hm, I'd be willing to sponsor and mentor those uploads, but I cannot commit
> to maintaining them as well. Is there anybody out there who would?
>
> > == What is DNF? ==
> [...]
> > == Why does Debian need DNF? ==
> [...]
> > == Prerequisites ==
> [...]
> > == Package List ==
> [...]
> > == Repository ==
> [...]
>
> all very very nice! It would be a pity to have this rot, but then, without
> maintenance it will anyway eventually...
>
>
> --
> cheers,
> Holger
>

Hi Holger

I'd be happy to take on maintenance of this package, and may be anything
else that's Qubes required but seems to be lapsing in Debian.
I'll do the necessary in the morning.

Also, I wonder if there would be value in getting Qubes packages in to
Debian, so they can be installed straight in to HVM - I seem to recall
this was raised some time back, but dont recall outcome. Waste of time?

cheers

unman

Reply | Threaded
Open this post in threaded view
|

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

Frédéric Pierret


On 2020-05-03 18:07, unman wrote:

> On Sun, May 03, 2020 at 12:03:40PM +0000, Holger Levsen wrote:
>> Hi Mihai,
>>
>> On Fri, Sep 13, 2019 at 05:36:55PM +0200, Mihai Moldovan wrote:
>>> I've packaged DNF
>>
>> cool!
>>
>>> for Debian and would like to find someone to take over these
>>> packages and maintain them as part of the distribution.
>>>
>>> I'm not a DD and while I believe the packages to be of reasonable if not high
>>> quality, I already have enough on my plate and know that I will not be able to
>>> properly maintain them, keep up with upstream releases etc.
>>> Point in case: while I did the original packaging more than a year, I only
>>> updated this set of packages recently when they actually broke with newer Fedora
>>> releases (i.e., they were too old to create newer Fedora changeroots when used
>>> by mock).
>>
>> hm, I'd be willing to sponsor and mentor those uploads, but I cannot commit
>> to maintaining them as well. Is there anybody out there who would?
>>
>>> == What is DNF? ==
>> [...]
>>> == Why does Debian need DNF? ==
>> [...]
>>> == Prerequisites ==
>> [...]
>>> == Package List ==
>> [...]
>>> == Repository ==
>> [...]
>>
>> all very very nice! It would be a pity to have this rot, but then, without
>> maintenance it will anyway eventually...
>>
>>
>> --
>> cheers,
>> Holger
>>
>
> Hi Holger
>
> I'd be happy to take on maintenance of this package, and may be anything
> else that's Qubes required but seems to be lapsing in Debian.
> I'll do the necessary in the morning.
unman, do you have any timeline available for this? We are currently facing the problem of making core-agent-dom0-updates not available in Debian due to missing yum/dnf in bullseye. If you lack time, I could manage to build the package for Qubes as a first step/test.

> Also, I wonder if there would be value in getting Qubes packages in to
> Debian, so they can be installed straight in to HVM - I seem to recall
> this was raised some time back, but dont recall outcome. Waste of time?
>
> cheers
>
> unman
>

Best,
Frédéric




signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DNF for Debian

YunQiang Su
In reply to this post by Mihai Moldovan
Mihai Moldovan <[hidden email]> 于2019年9月13日周五 下午11:46写道:

>
> Hi
>
>
> I've packaged DNF for Debian and would like to find someone to take over these
> packages and maintain them as part of the distribution.
>
> I'm not a DD and while I believe the packages to be of reasonable if not high
> quality, I already have enough on my plate and know that I will not be able to
> properly maintain them, keep up with upstream releases etc.
> Point in case: while I did the original packaging more than a year, I only
> updated this set of packages recently when they actually broke with newer Fedora
> releases (i.e., they were too old to create newer Fedora changeroots when used
> by mock).
>
>
>
> == What is DNF? ==
>
> For a long time, Fedora/RHEL/CentOS (and derivatives) used YUM as their default
> package manager. DNF is a feature-rich YUM fork intended to replace it
> eventually, using libsolv as its dependency solver, entered Fedora in version 18
> as an option and has been its default package manager since version 22. RHEL 8,
> based on Fedora 28, also already uses DNF as its default package manager.
>
>
>
> == Why does Debian need DNF? ==
>
> Debian already has packages for yum and mock. Building RPM packages on a Debian
> system is a supported use case already utilized by a (probably rather small

Just a story:
   In the last year, I tried to rebootstrap Fedora for MIPS based on Debian,
   and I was troubled lot due to difference of symbols of several libraries.

> amount) of users. That alone is normally not enough reason to introduce new
> packages, but newer Fedora versions use features like boolean (or rich)
> dependencies[0] that are plainly not supported by yum. Building such chroots
> will flat out fail. DNF is now a hard dependency for supporting newer Fedora and
> RHEL versions.
>
> Without DNF, Debian would at some point lose the ability to be used a build host
> for RPM packages.
>
> Debian does NOT need DNF as an additional native package manager, but that
> should be pretty clear. No sane user would (and should) try to mix dpkg/apt and
> rpm/{yum,dnf} packages on a Debian system.
>
>
>
> == Prerequisites ==
>
> Most packages within unstable/sid are new enough.
>
> The rpm source package needs a few rather trivial backports for new RPM tags -
> submitted as https://bugs.debian.org/940114
>
> The libsolv source package needs patches fixing its CMake integration, making it
> usable with the "rpmdb-in-homedir" patch that is applied to Debian's rpm package
> and enabling the COMPS feature - submitted as https://bugs.debian.org/889509
>
> Eventually, I'd like Debian to completely drop the "rpmdb-in-homedir" patch
> since it's causing more trouble than solving issues - a lengthy description of
> why that is can be found in https://debugs.debian.org/794495 . While that is not
> the case, we will have to patch libsolv to support that non-standard RPM behavior.
>
>
>
> == Package List ==
>
> === libcomps 0.1.11-1 ===
>
> Libcomps is library for structure-like manipulation of content in
> comps XML files. Supports reading/writing XML files and structure
> modifications.
>
> Needed by: dnf
>
>
> === librepo 1.10.5-1 ===
>
> A library providing C and Python (libcURL-like) APIs to
> download repository metadata.
>
> Needed by: libdnf
>
>
> === modulemd1 1.8.15-1 ===
>
> A C library for manipulating module metadata files.
>
> Needed by: libdnf, dnf
>
>
> === libdnf 0.35.3-1 ===
>
> A library providing simplified C and Python APIs to libsolv.
>
> Needed by: dnf
>
>
> === dnf 4.2.9-1 ===
>
> Package manager forked from Yum, using libsolv as a dependency resolver.
>
> Needed by: as explained above, also dnf-plugins-core
>
>
> === dnf-plugins-core 4.0.9-1 ===
>
> This package enhances DNF with builddep, config-manager, copr, debug,
> debuginfo-install, download, needs-restarting, repoclosure, repograph,
> repomanage, reposync, changelog and repodiff commands.
>
> Additionally provides generate_completion_cache passive plugin.
>
> Needed by: mocks operation (builddep for instance) (not a proper dependency yet)
>
>
>
> == Repository ==
>
> Source and binaries (for unstable/sid, amd64) can be found at
> https://packages.x2go.org/debian-test/pool/main/
>
> If you want to test that, use something like
>
> deb     http://packages.x2go.org/debian-test sid main
> deb-src http://packages.x2go.org/debian-test sid main
>
>
>
> == Personal Note ===
>
> I've been using DNF for the past one-and-a-half years for building RPM packages
> on a Debian stretch machine. The proposed packages contain a few patches needed
> for stretch integration (and stretch also needs changes to
> gobject-introspection, glib and util-linux for DNF to build and work correctly).
> I didn't want to rip them out and they don't cause trouble on newer-than-stretch
> systems since their effect is essentially deactivated there. They are, however,
> marked with "stretch" in the description and dropping them should be very easy.
>
> They seemed to be very usable and stable for my use case - building RPM packages
> via mock.
>
>
>
> Mihai
>
>
>
> [0] Debian/dpkg/apt has already known one of these "boolean(/rich) dependencies"
> for quite some time - OR dependencies. RPM adds further ones, like (A if B)
> which pulls in package A if B is already installed on the user system while
> installing the dependent package, (A if B else C), which is the but extended
> with a ternary term and crazier ones like (A with B), which instructs the solver
> to find ONE single package that fulfills both A and B. Confused? A and B need
> not be actual packages, it's totally valid for them to be other expressions,
> like fully virtual ones. RPM spec files can use any statement in Provides:
> clauses - and those can either live in a specific namespace (e.g.,
> "pkgconfig(rpm)", which looks for an "rpm" capability in the "pkgconfig"
> namespace) or in the global namespace (e.g., "mta", as a virtual package
> specification). Yes, it's complicated to understand and arguably error-prone
> (for humans), but the usage of such expressions is abundant within the
> repositories nowadays.
>


--
YunQiang Su

Reply | Threaded
Open this post in threaded view
|

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

Holger Levsen-2
In reply to this post by Unman
Hi unman,

On Sun, May 03, 2020 at 05:07:14PM +0100, unman wrote:
> I'd be happy to take on maintenance of this package, and may be anything
> else that's Qubes required but seems to be lapsing in Debian.

cool. I'll be happy to review & sponsor these uploads to Debian!

> Also, I wonder if there would be value in getting Qubes packages in to
> Debian, so they can be installed straight in to HVM - I seem to recall
> this was raised some time back, but dont recall outcome. Waste of time?

I gave up working on https://wiki.debian.org/Qubes/Devel as I believe
dom0 should use something more tailored and shrinked down system then
both Debian and Fedora are and because the Qubes and Debian release
cycles don't match at all, thus one will probably always need a Qubes
apt repo too.

I'm not sure to which packages / use-case you are refering to. Can you
explain again, please?
 

--
cheers,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

There are only two kinds of nazis: stupid ones and those without an excuse.
(Volker Strübing)

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DNF for Debian

Mihai Moldovan
In reply to this post by Holger Levsen-2
Sorry for the late response. I've been busy, and, honestly, also always forgot
to actually answer.


* On 5/3/20 2:03 PM, Holger Levsen wrote:
> hm, I'd be willing to sponsor and mentor those uploads, but I cannot commit
> to maintaining them as well. Is there anybody out there who would?

unman seems to be interested, if that's good enough, so there's that.


> all very very nice! It would be a pity to have this rot, but then, without
> maintenance it will anyway eventually...

Personally, I will have to "maintain" the package sets anyway, because I'm
building a lot of Fedora/CentOS packages in an automatic fashion on Debian.

This "maintenance" just means that I'll probably update stuff every half a year
or year, though, essentially "whenever it breaks" (which does tend to happen).

There's inevitably some bitrot involved, but I just don't have the time for
proper maintenance.


* On 5/25/20, 6:06 PM, unman wrote:
> That package is incredibly useful to us in Qubes, as you'll see.
> Where would I be able to pick up your package, and do any necessary work
> on them before uploading?

It's great if you have both a use case for it and are willingly to take over!

As given in the initial description, I've published source and binary packages
for Debian Unstable/Sid at https://packages.x2go.org/debian-test/pool/main/

Note that the binaries are a bit old by now and would probably like a rebuild,
but the source is still the one I'm also using on my package builder.

Also, the packages became a bit stale version wise (after all, they are 9 month
old by now) and some included patches have already been applied upstream. I
haven't tried updating (and testing any updates) yet, though, and probably won't
come to that shortly either.

Anyway, this said, it should still be a pretty solid base to build on.



Mihai


signature.asc (916 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DNF for Debian

Holger Levsen-2
hi Mihai,

On Fri, May 29, 2020 at 12:17:13PM +0200, Mihai Moldovan wrote:
> Sorry for the late response. I've been busy, and, honestly, also always forgot
> to actually answer.

thanks for your reply & don't worry, this happens often & to many people, me
included.
 
> unman seems to be interested, if that's good enough, so there's that.

that is good enough if not much better than that.
 
> > all very very nice! It would be a pity to have this rot, but then, without
> > maintenance it will anyway eventually...
>
> Personally, I will have to "maintain" the package sets anyway, because I'm
> building a lot of Fedora/CentOS packages in an automatic fashion on Debian.
>
> This "maintenance" just means that I'll probably update stuff every half a year
> or year, though, essentially "whenever it breaks" (which does tend to happen).
[...]

> As given in the initial description, I've published source and binary packages
> for Debian Unstable/Sid at https://packages.x2go.org/debian-test/pool/main/
>
> Note that the binaries are a bit old by now and would probably like a rebuild,
> but the source is still the one I'm also using on my package builder.
>
> Also, the packages became a bit stale version wise (after all, they are 9 month
> old by now) and some included patches have already been applied upstream. I
> haven't tried updating (and testing any updates) yet, though, and probably won't
> come to that shortly either.
 
the important part is whether we'll get these packages ready and up to date
until end of 2020 *and* whether we can commit to maintain important fixes after that.

end of 2020 because of "key release dates" on https://release.debian.org/

it's ok(ish) if the stuff is outdated today, but in 6 month it really should be current.
(and then after the release we can slack a bit again, though usually it's
less effort to always package and upload the latest version.)


--
cheers,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DNF for Debian

Mike Gabriel-4
Hi Holger, hi Mihai,

Am Freitag, 29. Mai 2020 schrieb Holger Levsen:

> hi Mihai,
>
> On Fri, May 29, 2020 at 12:17:13PM +0200, Mihai Moldovan wrote:
> > Sorry for the late response. I've been busy, and, honestly, also always forgot
> > to actually answer.
>
> thanks for your reply & don't worry, this happens often & to many people, me
> included.
>  
> > unman seems to be interested, if that's good enough, so there's that.
>
> that is good enough if not much better than that.
>  
> > > all very very nice! It would be a pity to have this rot, but then, without
> > > maintenance it will anyway eventually...
> >
> > Personally, I will have to "maintain" the package sets anyway, because I'm
> > building a lot of Fedora/CentOS packages in an automatic fashion on Debian.
> >
> > This "maintenance" just means that I'll probably update stuff every half a year
> > or year, though, essentially "whenever it breaks" (which does tend to happen).
> [...]
> > As given in the initial description, I've published source and binary packages
> > for Debian Unstable/Sid at https://packages.x2go.org/debian-test/pool/main/
> >
> > Note that the binaries are a bit old by now and would probably like a rebuild,
> > but the source is still the one I'm also using on my package builder.
> >
> > Also, the packages became a bit stale version wise (after all, they are 9 month
> > old by now) and some included patches have already been applied upstream. I
> > haven't tried updating (and testing any updates) yet, though, and probably won't
> > come to that shortly either.
>  
> the important part is whether we'll get these packages ready and up to date
> until end of 2020 *and* whether we can commit to maintain important fixes after that.
>
> end of 2020 because of "key release dates" on https://release.debian.org/
>
> it's ok(ish) if the stuff is outdated today, but in 6 month it really should be current.
> (and then after the release we can slack a bit again, though usually it's
> less effort to always package and upload the latest version.)
>

As I am involved in the same upstream project as Mihai (X2Go), I also have am interest in dnf for Debian. I can be of help with doing sponsored uploads and such.

I guess, Mihai and I can stick our heads together until the end of the year and get dnf into shape. Most of the work has been done by Mihai already anyway.

Greets,
Mike

--
Gesendet von meinem Fairphone (powered by SailfishOS)
Reply | Threaded
Open this post in threaded view
|

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

Frédéric Pierret
In reply to this post by Holger Levsen-2

On 2020-05-29 12:43, Holger Levsen wrote:

> hi Mihai,
>
> On Fri, May 29, 2020 at 12:17:13PM +0200, Mihai Moldovan wrote:
>> Sorry for the late response. I've been busy, and, honestly, also always forgot
>> to actually answer.
>
> thanks for your reply & don't worry, this happens often & to many people, me
> included.
>  
>> unman seems to be interested, if that's good enough, so there's that.
>
> that is good enough if not much better than that.
>  
>>> all very very nice! It would be a pity to have this rot, but then, without
>>> maintenance it will anyway eventually...
>>
>> Personally, I will have to "maintain" the package sets anyway, because I'm
>> building a lot of Fedora/CentOS packages in an automatic fashion on Debian.
>>
>> This "maintenance" just means that I'll probably update stuff every half a year
>> or year, though, essentially "whenever it breaks" (which does tend to happen).
> [...]
>> As given in the initial description, I've published source and binary packages
>> for Debian Unstable/Sid at https://packages.x2go.org/debian-test/pool/main/
>>
>> Note that the binaries are a bit old by now and would probably like a rebuild,
>> but the source is still the one I'm also using on my package builder.
>>
>> Also, the packages became a bit stale version wise (after all, they are 9 month
>> old by now) and some included patches have already been applied upstream. I
>> haven't tried updating (and testing any updates) yet, though, and probably won't
>> come to that shortly either.
>  
> the important part is whether we'll get these packages ready and up to date
> until end of 2020 *and* whether we can commit to maintain important fixes after that.
>
> end of 2020 because of "key release dates" on https://release.debian.org/
>
> it's ok(ish) if the stuff is outdated today, but in 6 month it really should be current.
> (and then after the release we can slack a bit again, though usually it's
> less effort to always package and upload the latest version.)
>
>
Hi everyone,
I've packaged for Qubes all the work (not the dnf plugins as we don't need it currently) of Mihai with little few adjustments:

https://github.com/fepitre/qubes-libcomps
https://github.com/fepitre/qubes-librepo
https://github.com/fepitre/qubes-libsolv
https://github.com/fepitre/qubes-libmodulemd1
https://github.com/fepitre/qubes-libdnf
https://github.com/fepitre/qubes-dnf

I've built and tested all of them into Bullseye. With this freshly created bullseye template as UpdateVM, it makes dom0 update working like a charm!

I can help into testing/maintaining/any other thing needed to make things moving forward for Bullseye and especially having DNF in Debian.

Best regards,
Frédéric



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Frédéric Pierret
Hi,
I've published on Debian mentors the corresponding packages:

- libcomps
- librepo
- modulemd1
- libdnf
- dnf

There is mostly one commit above the source of Mihai with "Uploaders" 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.

Best regards,
Frédéric

On 2020-06-21 21:31, Frédéric Pierret wrote:

>
> On 2020-05-29 12:43, Holger Levsen wrote:
>> hi Mihai,
>>
>> On Fri, May 29, 2020 at 12:17:13PM +0200, Mihai Moldovan wrote:
>>> Sorry for the late response. I've been busy, and, honestly, also always forgot
>>> to actually answer.
>>
>> thanks for your reply & don't worry, this happens often & to many people, me
>> included.
>>  
>>> unman seems to be interested, if that's good enough, so there's that.
>>
>> that is good enough if not much better than that.
>>  
>>>> all very very nice! It would be a pity to have this rot, but then, without
>>>> maintenance it will anyway eventually...
>>>
>>> Personally, I will have to "maintain" the package sets anyway, because I'm
>>> building a lot of Fedora/CentOS packages in an automatic fashion on Debian.
>>>
>>> This "maintenance" just means that I'll probably update stuff every half a year
>>> or year, though, essentially "whenever it breaks" (which does tend to happen).
>> [...]
>>> As given in the initial description, I've published source and binary packages
>>> for Debian Unstable/Sid at https://packages.x2go.org/debian-test/pool/main/
>>>
>>> Note that the binaries are a bit old by now and would probably like a rebuild,
>>> but the source is still the one I'm also using on my package builder.
>>>
>>> Also, the packages became a bit stale version wise (after all, they are 9 month
>>> old by now) and some included patches have already been applied upstream. I
>>> haven't tried updating (and testing any updates) yet, though, and probably won't
>>> come to that shortly either.
>>  
>> the important part is whether we'll get these packages ready and up to date
>> until end of 2020 *and* whether we can commit to maintain important fixes after that.
>>
>> end of 2020 because of "key release dates" on https://release.debian.org/
>>
>> it's ok(ish) if the stuff is outdated today, but in 6 month it really should be current.
>> (and then after the release we can slack a bit again, though usually it's
>> less effort to always package and upload the latest version.)
>>
>>
>
> Hi everyone,
> I've packaged for Qubes all the work (not the dnf plugins as we don't need it currently) of Mihai with little few adjustments:
>
> https://github.com/fepitre/qubes-libcomps
> https://github.com/fepitre/qubes-librepo
> https://github.com/fepitre/qubes-libsolv
> https://github.com/fepitre/qubes-libmodulemd1
> https://github.com/fepitre/qubes-libdnf
> https://github.com/fepitre/qubes-dnf
>
> I've built and tested all of them into Bullseye. With this freshly created bullseye template as UpdateVM, it makes dom0 update working like a charm!
>
> I can help into testing/maintaining/any other thing needed to make things moving forward for Bullseye and especially having DNF in Debian.
>
> Best regards,
> Frédéric
>
>


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Peter Pentchev
On Thu, Jul 02, 2020 at 10:34:19AM +0200, Frédéric Pierret wrote:
> Hi,
> I've published on Debian mentors the corresponding packages:
>
> - libcomps
> - librepo
> - 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 did not react sooner and you may have done some work that may
have duplicated mine... that's kind of the point of ITP bugs though :)

> - libdnf
> - dnf
>
> There is mostly one commit above the source of Mihai with "Uploaders"
> 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.
BTW would some of these be better in the RPM packaging group?

G'luck,
Peter

> On 2020-06-21 21:31, Frédéric Pierret wrote:
> >
> > On 2020-05-29 12:43, Holger Levsen wrote:
> >> hi Mihai,
> >>
> >> On Fri, May 29, 2020 at 12:17:13PM +0200, Mihai Moldovan wrote:
> >>> Sorry for the late response. I've been busy, and, honestly, also always forgot
> >>> to actually answer.
> >>
> >> thanks for your reply & don't worry, this happens often & to many people, me
> >> included.
> >>  
> >>> unman seems to be interested, if that's good enough, so there's that.
> >>
> >> that is good enough if not much better than that.
> >>  
> >>>> all very very nice! It would be a pity to have this rot, but then, without
> >>>> maintenance it will anyway eventually...
> >>>
> >>> Personally, I will have to "maintain" the package sets anyway, because I'm
> >>> building a lot of Fedora/CentOS packages in an automatic fashion on Debian.
> >>>
> >>> This "maintenance" just means that I'll probably update stuff every half a year
> >>> or year, though, essentially "whenever it breaks" (which does tend to happen).
> >> [...]
> >>> As given in the initial description, I've published source and binary packages
> >>> for Debian Unstable/Sid at https://packages.x2go.org/debian-test/pool/main/
> >>>
> >>> Note that the binaries are a bit old by now and would probably like a rebuild,
> >>> but the source is still the one I'm also using on my package builder.
> >>>
> >>> Also, the packages became a bit stale version wise (after all, they are 9 month
> >>> old by now) and some included patches have already been applied upstream. I
> >>> haven't tried updating (and testing any updates) yet, though, and probably won't
> >>> come to that shortly either.
> >>  
> >> the important part is whether we'll get these packages ready and up to date
> >> until end of 2020 *and* whether we can commit to maintain important fixes after that.
> >>
> >> end of 2020 because of "key release dates" on https://release.debian.org/
> >>
> >> it's ok(ish) if the stuff is outdated today, but in 6 month it really should be current.
> >> (and then after the release we can slack a bit again, though usually it's
> >> less effort to always package and upload the latest version.)
> >>
> >>
> >
> > Hi everyone,
> > I've packaged for Qubes all the work (not the dnf plugins as we don't need it currently) of Mihai with little few adjustments:
> >
> > https://github.com/fepitre/qubes-libcomps
> > https://github.com/fepitre/qubes-librepo
> > https://github.com/fepitre/qubes-libsolv
> > https://github.com/fepitre/qubes-libmodulemd1
> > https://github.com/fepitre/qubes-libdnf
> > https://github.com/fepitre/qubes-dnf
> >
> > I've built and tested all of them into Bullseye. With this freshly created bullseye template as UpdateVM, it makes dom0 update working like a charm!
> >
> > I can help into testing/maintaining/any other thing needed to make things moving forward for Bullseye and especially having DNF in Debian.

--
Peter Pentchev  [hidden email] [hidden email] [hidden email]
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Mihai Moldovan
* 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 <[hidden email]>
>> 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


signature.asc (916 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Frédéric Pierret

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 <[hidden email]>
>>> 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


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Jonas Smedegaard-2
Quoting Frédéric Pierret (2020-07-02 18:44:24)

> 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.
Please do tell when you get the full picture¹ - I am still struggling at
it, after 19 years in Debian. :-)


 - Jonas

¹ Or take the shortcut and ask Paul Wise...

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc (849 bytes) Download Attachment