On 9/29/23 14:53, Matthew Vernon wrote:
Also, I think having Ceph publish .debs is useful more generally.
Sure! But I've been disappointed by it multiple times. Like when the
Ceph upstream started to use feature of GCC that were not available at
the time in Stable, and then Debian packages were given-up. It gave me
the feeling that it couldn't be trusted.
This time, it happened again for the Reef packages, that were not really
usable in Debian.
I'm really motivated to fix both the packages in Debian itself, and
upstream too. I'm convince that we should work on both.
Trying to maintain Ceph in Debian has to be done in Unstable/Testing,
which is a way more challenging than building for one's own unofficial
My Debian developer hat is sympathetic to this problem, too (but doesn't
have a lot of free time!). I think I'm inclined to agree with Bernd that
it may not be a valuable use of time trying to get packages built for
architectures that Ceph upstream don't support, particularly given how
resource-hungry the build process is.
I don't agree with this, especially considering we need librbd for many
packages in Debian. I counted 10 packages in Debian that have
build-depends on librbd-dev or librados-dev. If Ceph gets removed from
Debian, then the support for Ceph by those packages is gone too...
And, obviously, if we can get debian/ under the upstream main branch
into a better state, that makes everyone's lives easier - upstream
packages build better, and distros don't have to re-do the packaging work.
Definitively, I'm all for getting all of the work I did merged at some
point, and lower the differences as much as possible. I also think it's
a waste of time if we work on things twice (upstream, like you did, and
downstream, like I did).
My Debian packaging is also a way more Debian policy compliant than
what I saw from upstream. For example, I noticed that during the
build, Ceph
Yes; I was trying to do a minimum-viable-PR sort of job to try and get
reef packages built again - so I fixed the most serious errors (like the
lack of copyright file) where they could be done with minimal changes. I
wasn't intending that to be the final state of packaging for main.
Hopefully, we can get to a state where the diff between the Debian
package and the upstream Ceph one is very small.
So, Matthew, would you like to do packaging with me directly in
Debian? If so, I warmly welcome you in the #debian-openstack IRC
channel in OFTC if you would like to kickstart this (or we continue by
email if you prefer).
Particularly if we can arrange for packaging improvements to end up in
Ceph main (and thus subsequent releases, and thus hopefully images), I
may well be able to carve out some time to do so.
Great! The question is: where to start. What I envisioned was fixing all
I could on the Debian side of things first, as this wouldn't depend on
having patches merged upstream, like you experimented (as I saw it, it
looked kind of frustrating to see nobody seemed to care at first).
I don't think I should change my workflow for the moment, and probably
polishing things in Debian will get faster to the end result. But I'm
opened to do differently if you think I should.
Cheers,
Thomas Goirand (zigo)
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
