| Summary: | app-portage/flaggie: since portage-2.1.9 package.keywords file deprecated | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
| Component: | Current packages | Assignee: | Michał Górny <mgorny> |
| Status: | RESOLVED FIXED | ||
| Severity: | QA | CC: | dev-portage, grygoriy.fuchedzhy |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Michał Górny
2010-12-19 19:00:03 UTC
(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. |