New USES=autoplist: Generates plist automatically for large projects

[yuri]

Summary

While updating math/vtk, I found that its plist has thousands of files, a lot of optional and multi-optional files.
It is beneficial to just generate the plist autiomatically in this case, rather than manually updating and debugging it for hours (math/vtk takes a long time to build).

Therefore, suggesting USES=autoplist.

[yuri]

This comment was removed by yuri.

[yuri]

This comment was removed by yuri.

[adamw]

I am not against the idea of this. There definitely are ports that have massive plists that change often, and many of those ports repeat a similar block to generate their own.

Autoplist ability hasn't been baked in yet because we absolutely want static plists whenever possible. Static plists are an important maintainer check and allow end-users to quickly figure out which port installs a particular file. There would need to be a policy of when autoplist is and isn't appropriate.

Mk/Scripts/check-stagedir.sh

18

You're introducing a new variable here, with a meaning that differs from the $BATCH that is used elsewhere.

Consider naming it what it is: ${USES_AUTOPLIST:=no} or something.

Mk/Uses/autoplist.mk

17

The problem here is that now static and dynamic plists are mutually exclusive. Is it possible to mix the two, i.e. have autoplist fill in all the files that weren't named in the pkg-plist?

[yuri]

Renamed the variable, made it internal.

[yuri]

Mk/Uses/autoplist.mk

17

It is impossible to mix the two. Merging would be an additional functionality with higher complexity and questionable usefulness IMO.

[yuri]

Mk/Scripts/check-stagedir.sh

18

I renamed the variable, made it explicitly internal. Naming it USES_x would have made it look like it introduces some USES clause, when it is not.

[mat]

I will ALWAYS be against a generic autoplist.

It means nobody will ever check what files are packaged, and it is very, very, very bad.

If you need to do auto-plist in a port, because, for instance, the plist is huge, is is very easy, you add:

post-install:
        @cd ${STAGEDIR} && find -f * -type f >> ${TMPPLIST} && find -f * -type d -empty | sed -e 's/^/@dir /' >> ${TMPPLIST}

But a generic way of saying "I don't care whatever is in my package" is wrong.

Mk/Uses/autoplist.mk

16

Using makeplist is a very bad idea, it is intended for human consumption, not machine consumption.

[yuri]

In D13181#275228, @mat wrote:

I will ALWAYS be against a generic autoplist.

It means nobody will ever check what files are packaged, and it is very, very, very bad.

If you need to do auto-plist in a port, because, for instance, the plist is huge, is is very easy, you add:

post-install:
        @cd ${STAGEDIR} && find -f * -type f >> ${TMPPLIST} && find -f * -type d -empty | sed -e 's/^/@dir /' >> ${TMPPLIST}

But a generic way of saying "I don't care whatever is in my package" is wrong.

Thanks Mat.