Re: embedded modules at build time, and inc::latest best practice discussion
- To: debian-perl@lists.debian.org
- Subject: Re: embedded modules at build time, and inc::latest best practice discussion
- From: Clément Hermann <nodens@nodens.org>
- Date: Mon, 2 Sep 2019 10:53:55 +0200
- Message-id: <[🔎] 335e39f9-9a9e-6b9a-912d-6916e3e49c4b@nodens.org>
- In-reply-to: <20190831132356.GF23464@jadzia.comodo.priv.at>
- References: <f5fa7686-0ccd-180b-d390-002a39586a05@nodens.org> <8a94dfc9-68ea-d745-7e96-cf354bd10764@nodens.org> <085aa304-e393-8f6a-9bc1-2db06931abce@nodens.org> <20190831132356.GF23464@jadzia.comodo.priv.at>
Hi,
On 31/08/2019 15:23, gregor herrmann wrote:
> On Wed, 21 Aug 2019 22:48:30 +0200, Clément Hermann wrote:
>
>> Friendly ping!
>>
>> I updated the wording a bit. I also created a merge request on Salsa:
>> https://salsa.debian.org/perl-team/perl-team.pages.debian.net/merge_requests/1
>>
>
> Sorry for the delay, and thanks for your work on this.
Thanks for your comments!
> Here's the current text:
>
>
> | =head1 Embedded modules in inc/
> |
> | Some distributions use embedded modules in inc/, e.g as part of the build system.
> | While is it OK to have code in inc/ to extend an existing build system (e.g.
> | B<Module::Build>) or Tests, a module used for building shouldn't be embedded
> | but instead packaged in Debian and added as a C<Build-Depends:> entry, while
> | making sure the embedded version isn't used during package build.
> |
> | There are some exceptions to this rule, currently:
> | =over 4
> |
> | =item *
> |
> | Packages using B<inc::latest> can continue to use it, but must provide versioned
> | C<Build-Depends> accordingly to make sure the embedded version isn't used.
> |
> | =item *
> |
> | Using B<Modules::Install> as Debian packages has so far proven
> | mostly unsuccessful and is considered acceptable, but we expect that for a new package, the packager would at least try to use a packaged version.
> |
> | =item *
> |
> | Modules using B<Alien::*> are currently considered problematic but acceptable,
> | as they prove difficult to package and require a lot of fiddling with the build
> | system, which would probably amount to maintaining a fork of the module.
> |
> | =back
>
>
> Some thoughts:
>
> - Maybe it would be clearer to talk about "third-party modules" or
> "embedded third-party modules" as that is the point of the
> initiative? This might save us references to Module::Build (where
> ony one ist left, the other which was originally there is already
> gone anyway).
Yes. That is my point anyway, and this is indeed clearer.
> - In the first paragraph I'm not sure I understand the word "Tests".
I meant module tests. I agree it's less problematic for tests than for
build, since nothing ends up in the resulting package, but I think it's
better to explicitely build-depends on third-party modules anyway. The
rule could be more relaxed if the module is only used for tests, though.
> - (nitpick) In several places Build-Depends: might be extended by
> Build-Depends-Indep:
ACK.
> - In the Module::Install paragraph, there seems to be something missing
> - what exactly was unsuccessful? I assume removing the embedded
> inc/Module/Install* parts and using the packaged one.
> (Interestingly I seem to remember that this has worked previously
> but it also failed for me in my last try …)
> Ah, maybe "unsuccessful" → "harmless"?
I remember it failing, but I failed to check why in a timely fashion,
and now I don't remember exactly what failed…
Indeed "mostly harmless"
> - For Alien::* it's more that that they are difficult to remove than
> to package?
yes, right.
> Let's try to put this into POD:
>
>
> =head1 Embedded third-party modules in inc/
>
> Some distributions ship embedded modules in inc/, e.g as part of the
> build system or for testing. While it is OK to have own code in inc/
> to extend an existing build system (e.g. B<Module::Build>), an
> embedded B<third-party> module used for building or testing shouldn't
> be used but instead packaged in Debian and added as a
> C<Build-Depends{,-Indep}> entry, while at the same time making sure
> the embedded version isn't used during package build.
>
> There are some exceptions to this rule, currently:
> =over 4
>
> =item *
>
> Packages using B<inc::latest> can continue to use it, but mus
> provide versioned C<Build-Depends{,-Indep}> accordingly to make sure
> the embedded version isn't used.
>
> =item *
>
> Using B<Modules::Install> in Debian packages has so far proven mostly
> harmless and is considered acceptable; replacing the embedded
> fragments with the packaged C<libmodule-install-perl> doesn't always
> work, but we expect that for a new package the packager would at
> least try to use the packaged version.
maybe "for a new package or when upgrading to last upstream version" ?
> =item *
>
> B<Alien::*> modules are currently considered problematic in general
> but acceptable as build dependencies, as they prove difficult to
> remove and require a lot of fiddling with the build system, which
> would probably amount to maintaining a fork of the module.> =back
>
>
> What do people think?
Looks good to me!
Thanks for taking the time to look into this :)
Cheers,
--
nodens
Reply to: