Re: RFC: Standardizing source package artifacts build paths

[Guillem Jover <guillem@debian.org>]

On Sun, 2020-03-29 at 22:48:04 +0200, Marco d'Itri wrote:
> On Mar 29, Guillem Jover <guillem@debian.org> wrote:
> > While it's true that we might need to use such pathnames in debian/rules
> > or debhelper fragment files (which some might consider ugly), IMO that
> > has always felt like a sign that there's something missing in our
> > packaging helpers/tools.

> If you believe this then it means that you have been maintaining too 
> modern or too much simple packages.

Aww thanks, you are, as always, way too kind, and you probably even
listed too many reasons there.

> https://salsa.debian.org/md/inn/-/blob/master/debian/rules
> https://salsa.debian.org/md/inn2/-/blob/master/debian/rules
> https://salsa.debian.org/md/kmod/-/blob/master/debian/rules
> https://salsa.debian.org/md/binkd/-/blob/master/debian/rules
> https://salsa.debian.org/md/libxcrypt/-/blob/master/debian/rules

Most of these show some of the things I had in mind. Which have not
been supported (easily) in the past or yet by our packaging toolchain,
like:

  - declarative file metadata,
  - renaming files,
  - flavor builds (like udeb vs no-udeb, or w/ features disabled in
    configure, etc.),

Some other usages there though, look like things that can really be
simplified in the packaging, by say, just:

  - using dh_install, dh_link and friends,
  - being explicit in things to install in the .install fragments
    instead of just adding whole hierarchies,
  - using a temporary destdir (like debhelper does by default) and only
    installing the desired pathnames to the final installation directory.

Other things there can be simplified by improving the upstream build
system, also by parametrizing things, and submitting these upstream or
just carrying as local patches.

So yes, thanks, to me these examples seem to still confirm that the
explicit usage of the staged directories is an indication of things that
need fixing or improving in either the packaging or the toolchain.

And, of course there are always going to be remaining sticking points
not covered by features I or others have in mind, but IMO their presence
will still mean there's something to improve somewhere.

Regards,
Guillem