[ 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