[ Sorry, have not seen this up to now as the Debian BTS does not automatically CC people, that needs to be done explicitly. ]
Hi! On Thu, 2021-11-04 at 08:44:57 -0700, LEO PUVILLAND wrote: > What do you mean by hardcoded dependencies? 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. > > 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. > > 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. 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
