#1163 Issue closed: packaging/debian still needed ?

Labels: discuss / RFC, fixed / solved / done

frediz opened issue at 2017-01-11 12:12:

Hi,
since version 1.19, I've packaged Relax-and-Recover as "rear" for Debian : https://tracker.debian.org/pkg/rear .
I've pushed a new package for 2.00 and it should pop up soon.
It's available in Debian Unstable only at the moment, but I hope it will reach Stable.
As a side effect, rear is available for Ubuntu Zesty : https://launchpad.net/ubuntu/+source/rear

So I wanted to let you know and maybe you want to take some action concerning "packaging/debian" and the make "deb" target .
Anyway, do not hesitate to communicate with me for Debian and Ubuntu packaging.

F.

gdha commented at 2017-01-11 12:29:

@frediz Great work - thank you so much.
Input is more then welcome as we are all very novice deb packagers, and a pull request is always useful to improve this.
BTW, if you push into debian - is there a special process behind it? I think so, as for fedora/rhel it is also not easy to become a validated packager (it took me 9 months)

jsmeix commented at 2017-01-11 13:15:

Hooray!
We have someone for Debian and Ubuntu!

Welcome @frediz !

jsmeix commented at 2017-01-18 08:24:

@frediz

FYI:
We have currently those Debian specific issues:
https://github.com/rear/rear/issues/1064
https://github.com/rear/rear/issues/940

Fixes must work backward compatible, cf.
https://github.com/rear/rear/wiki/Coding-Style

frediz commented at 2017-01-18 12:28:

To begin, packaging in Debian is almost always stored upstream Debian, which means
that storing the packaging files in the upstream project, generally doesn't make sense,
hence the current issue about removing packaging/debian .
I'm not going to maintain the packaging here in packaging/debian as it's not the
way to do in Debian, but I'd be glad to help in Debian bug tracking system and to
communicate and forward bugs, fixes, improvements here.
Now, for some reason, maybe it's still interesting for you to keep a packaging directory here,
and to keep "opensuse build service" build a .deb based on that (Note : I don't know if it's
possible to make "Opensuse build service" build a package from the package source in
Debian) .
Let me know your opinion on this.
I personally don't plan to support 2 packaging trees and would advise to remove packaging/debian and stop building .deb in opensuse build service, else people will be a bit
lost with 2 packages.
Or they should know that :

  • a bug against the .deb from opensuse should be reported here
  • a bug against the rear package from Debian should be reported in Debian

@jsmeix
Thanks for letting know ; I commented on these.

@gdha
I'm going to explain a few things about Debian packaging in general.
The Debian Maintainer (which is the Debian guy packaging the software) is supposed to be
the interface between Debian and the upstream project.
He will have the rights to update the package in Debian (or can be sponsored if he has no upload rights).
Bugs against the Debian packaging or about rear usage in Debian are opened in Debian Bug Tracking System and handled there.
If a bug is upstream, the Debian Maintainer will interact with the upstream ( an
issue in Github for instance in the case of rear) by forwarding the bug.

Now, maintaining a package in Debian doesn't necessarily mean being a "validated" packager.
You don't need a specific status to be able to submit your new packaging in Debian.
As I explained above, you can come with a packaging tarball and submit it to debian-
mentors mailing list and anyone can help by reviewing it. Then someone with upload
rights to the Debian archive and willing to sponsor this package will commit the packaging in Debian.
That means that you need this sponsor. Those people are called "Debian Developer".
So that's more a question of knowing how Debian works, how packages are integrated,
how the automated build system works, how the bug tracking system works etc than a question of status.
Now if you get enough knowledge and time you can become an official "Debian Maintainer"
which is a specific status with upload rights limited to specific pet packages.
Then comes the "Debian Developer, uploading" status, which mean full upload rights to
the whole Debian archive.

You can find muuuch more information here : https://www.debian.org/doc/

gdha commented at 2017-03-09 14:28:

@frediz Thank you for the in-depth explanation - I will add those links in our Download page

schlomo commented at 2017-05-21 06:09:

@frediz I recently updated my laptop to zesty and was very positively surprised:

$ rear
The program 'rear' is currently not installed. You can install it by typing:
sudo apt install rear

Thanks a lot!!!

About our make deb: It is there for the simple reason that we also do test on Debian/Ubuntu and then we also need to be able to create a proper DEB package with the correct dependencies.

For that reason alone I don't feel comfortable removing our Debian packaging stuff - how would I test ReaR on DEB-based systems then?

About keeping two source trees in sync: I can fully understand your concern here. Would it help if we give you commit access to ReaR so that you can work upstream? I think that it is in our interest to make ReaR "the best" Debian package it can be, feel free to propose any change you find necessary.

If that won't work for you then I guess that we will be pull your packaging into ReaR from time to time so that we can keep working on DEB-based systems.

I very much welcome professionalizing our DEB support, for example it seems to me that we cannot console the conflicting requirements for isolinux in older and newer Debian versions within ReaR as the debian build system does not support conditionals in the control file (similar to how our spec file caters for all different distros and versions).

gdha commented at 2017-06-01 05:36:

Links added to documentation via
https://github.com/rear/rear.github.com/commit/bd9c5c24ffa7f08a981de196a00235f3a2866cd5

gdha commented at 2018-11-04 10:47:

Issue can be closed IMHO

[Export of Github issue for rear/rear.]