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

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

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