|
Hello Christoph, Thanks for the reply... inline.. 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. Hmmm.. Ok. I had been using it for years and it prompts and places any configured dependencies into the resulting packages. I get it that it's not the right way to do things and that's why I'm trying to move over to the proper way. One thing I liked about checkinstall is that it's one, lightweight package. devscripts on the otherhand drags in a bunch of other packages. Oh well. "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. Got it. So the initial package list I came up with to do packaging was: sudo apt install devscripts fakeroot config-package-dev debhelper dh-exec dh-system Sounds like you recommend to REMOVE fakeroot? Maybe I should install "dpkg-dev" instead? linpac's debian/ directory still has some cruft that might be cleaned up, it just needs someone to do that. I'm working on that and might be put into it's develop branch today. One thing that you could maybe incorporate into linpac upstream is the debian/linpac.1 manpage. Will do! 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. I'm still new to the Debian packaging universe but should I file ticket here for the checkinstall package? If so, where should I go? 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. I've been using debuild w/o much issue but maybe "dpkg-buildpackage" is more appropriate for my usecase? 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. No doubt SF is an older than service than say Github or Gitlab but it's support for Git fork and merge requests is all the same. Works well. I do see your point that from package maintainers will feel they won't want to create an account on SF.net to offer up merge requests but sending an email to the original developer of the created changes isn't very hard. Anyway.. thanks for all your help --David |