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