Add autoplist support for USES=perl5

[swills]

Summary

This is just a first pass naive implementation for comments. It'll hopefully remove all pkg-plist and PLIST_FILES from p5- ports. I'll add that to the diff after some manual testing.

Test Plan

Local manual testing then full exp-run.

[swills]

Fix comment

[swills]

Properly place autoplist target after end of fix-perl-things target and make grep only avoid plist file

[mat]

All in all, I really do not like autoplists. It's like saying "I want this packaged, I don't care what is in it". And we care, not knowing when stuff gets removed, or added, is bad.

Mk/Uses/perl5.mk

297

That is not needed at all, plist contain either relative to PREFIX or absolute paths.

[mat]

While I agree that python needs an autoplist feature because there are too many variations of it what files are installed where depending on the Python version, the only thing that changes in a Perl module plist is the Perl version, and it does not, in my opinion, warrant an auto-plist feature.

[swills]

In D9331#193328, @mat wrote:

While I agree that python needs an autoplist feature because there are too many variations of it what files are installed where depending on the Python version, the only thing that changes in a Perl module plist is the Perl version, and it does not, in my opinion, warrant an auto-plist feature.

I hear you, I'm not particularly fond of the "just install whatever" model either. But we're already doing it for python and ruby modules, so maybe it's not so bad.

[mat]

I don't know exactly how differently the ruby gems install stuff depending on the ruby version, but the python modules would need 2 or 3 different plists depending on wether you use python 2, python 3 before 3.5 or python 3 starting at 3.5 (because they changed the file names, or something).
Like I said, the only thing that changes is the directory, and it is handled by the %%PERL_VER%% and such substitutions.

[bapt]

While I was a big opponent of the autoplist for many reason @mat is exposing and more, for cases where one have altready a static plist provided, I see no point in keeping pkg-plist, that will drastically reduce the size of the ports tree to be able to skip to plist files. when I see most people are now blindly doing make makeplist > pkg-plist and remove the first line then commit without checking it so in the end that won't change anything to have autoplist for those

[mat]

In D9331#194521, @bapt wrote:

when I see most people are now blindly doing make makeplist > pkg-plist and remove the first line then commit without checking it so in the end that won't change anything to have autoplist for those

What it changes is that people who actually read commit-email can do post commit reviews and yell "hey, you're doing something stupid here"

[bdrewery]

I for one support this and autoplist in general. I am not convinced by the counter arguments. I would prefer a blacklist than a whitelist as they are generally smaller, or even supporting both methods. And possibly an "overwrite" that allows @execs and @info and stuff. Having said that, we've had this debate plenty of times already. As bapt points out, people just take makeplist or poudriere output (makeplist) anyway. So there's little practical difference between autoplist and what we have now except more maintenance cost.

For these perl:autolist ports, how are they built? Is it some cpan tool or just an extract+copy to the stage? Is it possible a p5- port could have something in LOCALBASE/bin too? That would not be automatically added to the plist with this patch as far as a I can see.

[mat]

Whatever is decided here about auto plists, please do revert the fix-perl-things line.

[mat]

Also, please kindly revert the default USE_PERL5 line.

A port that sets:

USES=perl5

means it is going to use /usr/local/bin/perl when building and when running, it does not install any Perl modules. Perl modules are built and installed (with a very, very, few exceptions) using USE_PERL5=configure/modbuild/modbuildtiny.

[antoine]

• In my opinion this feature can't be on by default from day 1, this will break all QAT builds
• There are some cases where this feature doesn't make sense, why would a port that needs perl to build and to run, but doesn't install any perl module need this?

[swills]

Remove changes to USE_PERL5 and .packlist

[swills]

In D9331#194629, @bdrewery wrote:

I for one support this and autoplist in general. I am not convinced by the counter arguments. I would prefer a blacklist than a whitelist as they are generally smaller, or even supporting both methods. And possibly an "overwrite" that allows @execs and @info and stuff. Having said that, we've had this debate plenty of times already. As bapt points out, people just take makeplist or poudriere output (makeplist) anyway. So there's little practical difference between autoplist and what we have now except more maintenance cost.

Exactly, my goal was to allow the simple things to be done more easily. You can still add things to plist and manual plists still work the same. I've taken out any changes that weren't really needed, so all this does now is make it possible to use autoplist.

For these perl:autolist ports, how are they built? Is it some cpan tool or just an extract+copy to the stage? Is it possible a p5- port could have something in LOCALBASE/bin too? That would not be automatically added to the plist with this patch as far as a I can see.

The perl:autoplist ports would be built just as normal now, just that you wouldn't have to have a plist if it's not needed. I'm not sure I understand what you're asking about a cpan tool, but it should be possible to write a tool to generate p5- ports easily, at least to a first approximation. You would still need to manually add things from PREFIX/bin to the plist just as you do now with gem things that install things there and I think py- ports are the same as well.

[swills]

Removed.

[swills]

In D9331#194609, @mat wrote:

In D9331#194521, @bapt wrote:

when I see most people are now blindly doing make makeplist > pkg-plist and remove the first line then commit without checking it so in the end that won't change anything to have autoplist for those

What it changes is that people who actually read commit-email can do post commit reviews and yell "hey, you're doing something stupid here"

I agree, it does make it harder to know what's in a package. But, practically speaking, has it been a problem for py- or rubygem- packages? Not saying it doesn't matter, just trying to figure out how bad it is.

[brd]

This is a nice improvement to the framework!

[mat]

Mk/Uses/perl5.mk

323

This should probably be in the find command before -print as -not -name .packlist.

324–325

You could probably avoid running sed completely by running:

cd ${STAGEDIR} && ${FIND} -ds ${PREFIX}/${SITE_PERL_REL}

instead.

[swills]

Avoid grep and sed

[swills]

Make bash use of fdescfs use optional, disabled by default, and forced off when
disabled.

[swills]

Put correct patch back into arc