It would be beneficial for both usabillity and manageabillity if entries like kde-*\* ~x86 would be supported in package.keywords for example to make testing anything KDE... :) Hoping to see this feature soon. Best wishes in improving this tool, Alexia Death. P.S Do forgive me if this has been requested before. Search did not turn up anything...
Hmm, at most I'd support the notion of 'category/*' wildcards, but even that is more complicated to implement than one might think, as either a) we try to expand when parsing the files, which needs a portdbapi instance that isn't easily available at that stage or b) we'd have to add special case code all over the place Additionally this is rather easy to work around with portage-2.1 and using package.* directories, for your example you'd just do a cd $PORTDIR echo kde-*/* | grep metadata.xml > /etc/portage/package.keywords/kde Only real drawback is that you have to update/regenerate that list from time to time to include new packages, but even that could be automated with a postsync hook.
(In reply to comment #1) > echo kde-*/* | grep metadata.xml > /etc/portage/package.keywords/kde That should have read: ls -d kde-*/* | grep -v metadata.xml > /etc/portage/package.keywords/kde Right?
If implementing this within portage is difficult in existing framework a solution could be a new tool. New file package.*.wildcards that would have the wildcarded notation that is parsed into a package.*/wildgen file with a separate command on demand.and then the package.*/wildgen is used also... Keeping lines of script everywhere for this common task is uncomfortable...
(In reply to comment #3) > If implementing this within portage is difficult in existing framework a > solution could be a new tool. New file package.*.wildcards that would have the > wildcarded notation that is parsed into a package.*/wildgen file with a > separate command on demand.and then the package.*/wildgen is used also... > Keeping lines of script everywhere for this common task is uncomfortable... > Feel free to write it; essentially the only reason why it's not implemented already is because no one cares to work on it.
*** Bug 187312 has been marked as a duplicate of this bug. ***