Re: Question on best approach to add debian/ packaging files into Linpac source code tree
Hi David,
Re: David Ranch
> Ok, thanks for telling me that. My goal is to let people package Linpac
> (and ultimately other programs) more easily as I'm not a big fan of users
> running "make install" alone. I think all the dependency tracking, warnings
> when systems get OS updates, etc. is all invaluable. For the longest time,
> I've been recommending people to use "checkinstall" tool. This simple
> program doesn't drag in all the other packaging tool requirements that
> "devscripts" and "fakeroot" bring in.
Urgh. "checkinstall" will not bring you a quality package but just
drop the installed stuff into a .deb, with no curated list of
dependencies etc.
"fakeroot" is a lightweight wrapper that is even redundant today (put
"Rules-Requires-Root: no" in debian/control), and "devscripts" is just
a collection of scripts for maintainers usually *not* used at build
time. (That would be "debhelper".) The perceived overhead is really in
the amount of work necessary to create the files in debian/, but that
has been greatly reduced over the last years.
linpac's debian/ directory still has some cruft that might be cleaned
up, it just needs someone to do that.
One thing that you could maybe incorporate into linpac upstream is the
debian/linpac.1 manpage.
> Unfortunately the version of
> checkinstall that Debian packages has a known bug (
> https://github.com/opencv/opencv/issues/8897 ) when using Cmake that stops
> all that in it's tracks. A fix has been available from the checkinstall
> developer since 2017 but he hasn't tagged any new version of code so the
> Debian packages probably have no idea. Maybe this is someone in the Debian
> packaging universe can look at?
The problem is probably that all serious maintainers spend their time
on packages instead of working on tools they wouldn't touch with a 10m
pole.
That said there's surely value in having checkinstall, but it won't be
me to fix it.
> Understanding my goals, do you think that I should pursue with the "debuild"
> approach which is heavier weight for the user *or* maybe "checkinstall" is
> more appropriate?
If the debian/ directory is sane, "debuild" (from devscripts) or
"dpkg-buildpackage" (from dpkg-dev or build-essential) is painless.
> > > - Remove the "patches" directory as it's no longer needed - found in
> > > https://sources.debian.org/src/linpac/0.25-1/debian/patches/
> > The release tarball shouldn't have any patches, right.
>
> One thing I've never understood about the Debian packaging team is that they
> come up with various fixes for programs and add them to the packaging system
> but I've never heard of that packager NOTIFYING the upstream project of the
> fix and asking them to adopt it. A good example of this is the current
> Linpac 0.25 package in Sid/unstable has a fix yet I was never notified of
> it's existence. This issue was addressed independently but that resulted in
> double work. Oh well but it seems like an area for improvement for the
> community.
Maintainers should actually forward patches, but time is limited so it
doesn't always happen.
Frankly, I would suggest moving linpac from sourceforge to some other
hosting service. SF's interface is so baroque for today's standards so
I suspect many maintainers will refrain from submitting patches there
instead of quickly dropping a pull request on github or gitlab.com.
Christoph
Reply to: