Re: embedded modules at build time, and inc::latest best practice discussion
Please disregard this message and check the one I just resent, without
the truncated references ;)
On 08/12/2018 13:21, Clément Hermann wrote:
> 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,
>
Reply to: