* Package name : makedeb Version : 7.1.2+bugfix1 Upstream Author : Hunter Wittenborn <hunter@hwittenborn.com> * URL : https://makedeb.hunterwittenborn.com * License : GPLv2 Programming Lang: Bash Description : The modern packaging tool for Debian archives. makedeb is a packaging tool for Debian-based systems that aims to be simple and easy to use, whilst still remaining just as powerful as standard Debian tooling. makedeb uses a packaging format that's aiming to be simpler and easier to get a hold of than standard Debian packaging, so adding this program would help more users begin packaging for Debian. Hunter maintains upstream while I maintain the debian part.
Hi! Hmm, I think I take issue with this description. :) While I can agree there's much that can be changed in dpkg and related tooling such as debhelper to improve packaging workflows and make this a more integrated and easy thing to approach for new people, I'm not seeing how makedeb is neither "The" nor "modern" tool for this. I feel it suffers from pretty much the same problems as fpm (see <https://github.com/jordansissel/fpm/issues/409> or <https://bugs.debian.org/688896>). I'm afraid, simple here implies potentially incorrect (see the comments on the links about ignoring dependency information from shlibs/symbols files f.ex), checking the upstream repo I see dependencies are being hardcoded, which seem even worse than I'd expect. This also implies much of the current automatic handling found in, say, debhelper and related tools is skipped, which does not look would make it easier to generate properly integrated packages. I think this makes the packaging experience even more confusing, as these people might still need to have to deal with proper Debian packaging anyway. Thanks, Guillem
Hey Guillem! What do you mean by hardcoded dependencies? makedeb doesn't use the native debian format and I believe that's a design choice, instead it uses the alternate PKGBUILD format, inspired by Arch Linux. I looked at the issues you mentioned and I can see your point. However, isn't one of the core principles of Linux freedom of choice? This is simply another way to package for Debian. Thanks for your feedback, I will talk with the upstream maintainer :) - Leo
[ Sorry, have not seen this up to now as the Debian BTS does not automatically CC people, that needs to be done explicitly. ] Hi! AFAICS with makedeb you hardcode f.ex. shared libraries in the dependencies such as in: https://mpr.hunterwittenborn.com/cgit/aur.git/tree/PKGBUILD?h=polybar#n10 instead of both inferring the package name the libraries used come from, and retrieving the correct versioned dependency information from the shlibs and/or symbols files. (See the man pages for dpkg-shlibdeps, deb-shlibs, deb-symbols and deb-src-symbols). This means these can end up from encoding incorrect dependency relationships that can cause linker errors, to segfaults due to ABI requirements not fulfilled. Or simply require mass manual updates when the SONAME is bumped but the API is preserved, which would otherwise only require a rebuild. Many of the debhelper tooling contains code implementing policies and integration that is expected from packages that are installed on Debian systems. Sure, I understand that, and can see the appeal for some people coming from the Arch Linux world. But that still will just not produce fully and correctly integrated Debian packages. I don't think freedom of choice is a core principles of Linux (the kernel? :), nor the FOSS movement. People might want that, and that's fair, but we should never forget that more choice can also bring more confusion, worse user experience, etc. In this case I think upstream should clearly note all limitations with this approach, and start by not stating this is “the modern packaging tool for Debian”. :) Including (currently) this in Debian, to me gives the impression this packaging method will give results of similar quality and integration as packaging with native tools, which seems undesirable, TBH. Thanks, Guillem
I see what you mean. I will talk with the upstream maintainer on fixing those issues, and in the meantime there are lintian errors to fix. However, about those hard coded deps, that’s a user submitted package and packages on the AUR could have those same issues. We fix those issues as they arise but it’s still at the user’s discretion. Maybe it would help if we listed limitations as you said in the readme and rework that title? Let me know what you think. Thanks, Leo -- Leo Puvilland, <lpuvilla0001@mymail.lausd.net> [image: Codecademy Cat Coding]
Hey Guillem! We have reworked the description and title, it's now "A simplicity-focused packaging tool for Debian archives". Do you have any more thoughts about this? We are trying to say that there is nothing official about this project and that it is not better or a replacement in any way than the native debian packaging, simply an alternative. Cheers, Leo
Control: retitle -1 ITP: makedeb -- A simplicity-focused packaging tool for Debian archives packaging tool for Debian archives". Retitling bug accordingly.