[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On Mon, 10 Dec 2018 16:03:56 +0100, Clément Hermann wrote:

> > I guess there are different cases, the most prominent being
> > Module::Install (which seems to get less and less popular);
> > inc::latest; random Test::* modules; probably others. So we'd need to
> > decide what to check for and what to do in those cases.
> > 
> > Or maybe only inc::latest is a problem as it leads to kind of
> > unpredictable builds (different versions used)?
> 
> As pointed out by intrigeri, the chance of it being an actual issue is
> small in the Perl ecosystem.

Thanks to intri for this analysis!
 
> However, I think that when, like in inc::latest case, the fix is
> actually quite easy, doesn't involve patching, or removing selected
> parts of the build system, we should fix it.

Makes sense.
 
> It would also be worth it to have a best practice for Module::Install
> and Module::Build: in the team package repos, I found 511 with vendored
> modules (see attached using_vendored_modules.list), and out of them, 379
> are for Module::Install or Module::Build (see attached
> using_Module-InstallBuild.list).

I'm not aware of problems with Module::Build. AFAIK it doesn't add
itself to inc/ (like Module::Install) but it allows to create derived
classes (inc/MyBuilder.pm etc.), which seems like an intended interface
for extending it. But I might be missing something of course.

> IMO, we should avoid, when possible, using vendored libraries if it's
> shipped in Debian. In policy terms, I see it as a "should" and not a
> "must": I don't see why we shouldn't fix it when we stumble on the issue
> but it might not warrant a systematic hunt. Module::Install/Build could
> be an exception, since it's really intended to work that way, it's no
> worse than a custom build system (and probably better). 

For Module::Install, IIRC the "fix" is to rm -r inc/ and build-depend
on libmodule-install-perl; still the question is if it's worth the
effort.

> In the case of
> inc::latest, I think it's just confusing and something needs to be done.

I think I agree on that :)
 
> As for tests, it's probably even more complex, I don't think there is a
> one-size-fits-all solution.

In cases of outdated embedded inc/Test/More.pm etc. rm'ing them or
moving them away might make sense. But if we want that we should find
a common way to do this.
 

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: John Zorn: Kanah (Sparks)

Attachment: signature.asc
Description: Digital Signature


Reply to: