embedded modules at build time, and inc::latest best practice discussion

[Clément Hermann <nodens@nodens.org>]

Hi all,


while working on liblist-moreutils-perl [1], I stumbled on issues with
embedded modules at build time (the infamous inc/).


Here, the upstream maintainer uses inc::latest. Which means, if we have
a more recent version available at build time, there is no need to
delete the non custom modules in inc/, just to make sure we have more
recent ones at build time with versionned build-depends. Of course you
need to make sure those are kept in sync with the versions in inc/ when
there's a new upstream release.

It's especially important for backports, when you have more chance to
have an older version of those modules available.


In this case, my approach was to add an explicit comment in d/control,
to warn the occasionnal contributor about this issue.

What do you think ? Is it enough ? Maybe a README.source is in order ?

AFAICS, Options might be:
1. patch inc::latest::private in the package to prevent usage of the
installed module
2. customise d/rules to remove inc/ altogether
3. what I've done: versionned Build-Depends and maybe a warning as
comment or README.source.

I think 1. and 2. might prove tricky in certain cases, and is definitely
more work, so I went for 3.

I saw a similar approach for instance in libfile-sharedir-perl [2],
which has a build-depends on libfile-sharedir-install-perl (>= 0.13).
Indeed, without the versioned build-dep, if you build this in a stretch
chroot (let's say you want an backport), you'll end up using the
embedded version.

In other cases, like  libalien-wxwidgets-perl [3], unless I'm missing
something, nothing is done, not even an unversionned build-depends, and
I don't see e.g. libarchive-extract-perl as a dep of any build-depends,
so I guess it's a bug? Aren't the inc/ modules used at build time in
this case?

It's not hard to detect those, and if it is and once we agree on the
right way to handle this I'll just add proper build-deps wherever we
have the case. Actually, maybe we should have a lintian check about this?


Comments and thoughts welcome!


Cheers,

-- 
nodens

[1]