As user reported on github: [quotation] Since portage-2.1.9 package.accept_keywords should be used instead of package.keywords, though package.keywords still works. Here is details from man portage: package.accept_keywords and package.keywords Per-package ACCEPT_KEYWORDS. Useful for mixing unstable pack‐ ages in with a normally stable system or vice versa. This will allow ACCEPT_KEYWORDS to be augmented for a single package. If both package.accept_keywords and package.keywords are present, both of them will be used, and values from package.accept_key‐ words will override values from package.keywords. The pack‐ age.accept_keywords file is intended to replace the package.key‐ words file, since profiles support a different form of pack‐ age.keywords which modifies effective KEYWORDS (rather than ACCEPT_KEYWORDS). So flaggie should gracefully handle this. If package.accept_keywords present, it should be used, if not - package.keywords should be used instead. Thank you. [/quotation] Zac, any thoughts?
(In reply to comment #0) > So flaggie should gracefully handle this. If package.accept_keywords present, > it should be used, if not - package.keywords should be used instead. Portage uses both if present, so flaggie should use both if it's going to be totally consistent with portage.
(In reply to comment #1) > (In reply to comment #0) > > So flaggie should gracefully handle this. If package.accept_keywords present, > > it should be used, if not - package.keywords should be used instead. > > Portage uses both if present, so flaggie should use both if it's going to be > totally consistent with portage. Yeah, that's what I thought. How about new entries? Should they go to .accept_keywords or .keywords? What if only one of these files exists, what if both do?
I guess new entries should go in .accept_keywords if it exists, otherwise in .keywords since there's no need to create a second file in that case.
(In reply to comment #3) > I guess new entries should go in .accept_keywords if it exists, otherwise in > .keywords since there's no need to create a second file in that case. How about the case when none of these files exist? Can I assume users aren't going to downgrade their portage?
Yeah, I would just use .accept_keywords if nothing exists. There's no good reason for people downgrade to less than portage-2.1.9.
I think there is one more option to solve this. As moving /etc/portage/package.keywords file to /etc/portage/package.accept_keywords is fast and easy thing for user. flaggie can use only *.accept_keywords file and just print warning in case if /etc/portage/package.keywords is present. User will have just run one mv command, and you will not have to add code to support already deprecated feature.
Well, assuming it would take a lot of work to cleanly support modifying both files (especially that I don't think package.accept_keywords can somehow force ignoring an entry from package.keywords without specifying any additional keyword), so I might indeed force transition with portage new enough. So, as I guess flaggie will do the following: 1) check for portage version, if <2.1.9 ignore package.accept_keywords completely and just use package.keywords (maybe warn about that file), 2) if both files exist, refuse to do anything unless user shows a will to merge them (i.e. through passing --migrate-package-keywords) or remove one of them, 3) if package.keywords exists, work on that, suggesting migration. Does that cover all the cases?
(In reply to comment #7) > 1) check for portage version, if <2.1.9 ignore package.accept_keywords > completely and just use package.keywords (maybe warn about that file), As I already mentioned on github: portage-2.1.9 is already stable, so when user will sync portage and get new flaggie which checks for portage verion he will also get at least portage-2.1.9, and emerge will insist to upgrade it before any other package update. So support for <portage-2.1.9 in flaggie wouldn't be necessary.
(In reply to comment #8) > (In reply to comment #7) > > 1) check for portage version, if <2.1.9 ignore package.accept_keywords > > completely and just use package.keywords (maybe warn about that file), > As I already mentioned on github: portage-2.1.9 is already stable, so when user > will sync portage and get new flaggie which checks for portage verion he will > also get at least portage-2.1.9, and emerge will insist to upgrade it before > any other package update. So support for <portage-2.1.9 in flaggie wouldn't be > necessary. Users do many things but not those they're told to do. I'd say users should have wget updated to last month's version -- but I still get new bugreports due to old wget.
Use a blocker if you want to ensure the new flaggie isn't installed with <portage-2.1.9.
(In reply to comment #10) > Use a blocker if you want to ensure the new flaggie isn't installed with > <portage-2.1.9. Yeah but I really don't want to enforce such a thing. The code should be fine with a little older version of portage, I think. At least it was the last time I checked it. Hmm, that reminds me I'd have to add PVs to portage RDEP in my packages.
Partially done. Now flaggie uses package.accept_keywords if it does exist, and refuses to run if both package.accept_keywords and package.keywords do exist. When none of the files exist, though, flaggie still uses package.keywords by default.
Ok, basically done in a way different than I proposed before: 1) flaggie reads both package.keywords & package.accept_keywords, 2) new entries go to package.accept_keywords (do not mistake with new keywords to existing entries), 3) --migrate-files can be used to get rid of package.keywords and move all entries to package.accept_keywords.
Fixed in app-portage/flaggie-0.0.4.