To keep the tree slim it would be nice to have a tool/repoman check to clean FILESDR for uneeded patches.
This is basicaly cantfix, with current architecture it is almost imposible to do what you want, at best efforts you can write faluty tool that will have lot of false positives. For more info how to do it talk with Christian (idl0r).
We'd need an EAPI extension which allows ebuilds to specify which files they consume in $FILESDIR, similar to SRC_URI.
Then it will be a future request. But there are many dead files in FILESDIR.
(In reply to comment #1) > This is basicaly cantfix, > with current architecture it is almost imposible to do what you want, > at best efforts you can write faluty tool that will have lot of false > positives. You'll always have false positives (bad!), but you can write something that does a good job for approx. 99% of the cases. I know, because I had to deal with the inverse problem of fetching files the ebuild needs. It basically breaks on people doing advanced bash (looping) tricks (mpfr) or with local variables (lua).
(In reply to comment #2) > We'd need an EAPI extension which allows ebuilds to specify which files they > consume in $FILESDIR, similar to SRC_URI. And you expect the devs to write an another, ineffective file list in ebuilds?
(In reply to comment #5) > (In reply to comment #2) > > We'd need an EAPI extension which allows ebuilds to specify which files they > > consume in $FILESDIR, similar to SRC_URI. > > And you expect the devs to write an another, ineffective file list in ebuilds? Shrug, I guess there are other was to accomplish it. Maybe it's easier if we have the variable refer to subdirectories inside FILESDIR, so the that all the files don't have to be explicitly listed in the ebuild.
> Shrug, I guess there are other was to accomplish it. Maybe it's easier if we > have the variable refer to subdirectories inside FILESDIR, so the that all the > files don't have to be explicitly listed in the ebuild. > That would work either as patch A for version x could also apply on version x+1 and reused in the x+1 ebuild. Only solution with subdirs would be a big duplication of patches.
(In reply to comment #7) > That would work either as patch A for version x could also apply on version x+1 > and reused in the x+1 ebuild. Only solution with subdirs would be a big > duplication of patches. You could allow each ebuild do specify multiple directories, and some of those directories could be shared between multiple ebuilds in order to avoid any duplication. For example, you could have MY_FILES="common $PV" to indicate that an ebuild consumes files from both the "common" and "$PV" subdirectories.
But do we really need this? I guess that if we start enforcing all those requirements, the effort needed to get it all working would be much larger than one required for a particular dev to check his/her files manually when mangling a package. Moreover, I guess many devs will simply not waste their time declaring new variables. Especially if they right now don't even think about checking their files/ subdirs.
*** This bug has been marked as a duplicate of bug 292847 ***
