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.
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).
- In the first paragraph I'm not sure I understand the word "Tests".
- (nitpick) In several places Build-Depends: might be extended by
Build-Depends-Indep:
- 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"?
- For Alien::* it's more that that they are difficult to remove than
to package?
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 must
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.
=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?
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- NP: Lightnin' Hopkins: Cryin' Shame
Attachment:
signature.asc
Description: Digital Signature