| Summary: | sys-apps/portage: glsa-check --list new behavior is deprecated | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Paul Varner (RETIRED) <fuzzyray> |
| Component: | Tools | Assignee: | Portage team <dev-portage> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | esigra, jakub.januszkiewicz, pauldv |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Paul Varner (RETIRED)
2009-08-18 19:41:24 UTC
As Robert Buchholz explained in bug #275105, comment #7, automatically injecting GLSAs when the --fix option is used is not a good idea. After giving it a thought, I have to agree. However, such a change should be communicated in some way, so that admins have an opportunity to update their scripts/workflows. Possible problem that this change introduces is someone writing a script which 1. uses --fix to automatically resolve GLSAs that don't affect their system, 2. notifies about all remaining GLSAs (the list generated with --list [without parameter]). Before gentoolkit 0.3 the notification would include only unapplied GLSAs that affect the system. Since 0.3 it would contain all GLSAs. Obviously, a proper solution would be to reduce the script to just notify about `glsa-check --list affected`, but the point is that 0.3 breaks something that used to work (even if it was not an optimal solution, as I know now). Not to make this any longer, I basically want to say that I understand and agree with the change in glsa-check, but information about the change should be provided in a way that would be impossible for admins to miss (ELOG would be a sufficient minimum, IMO). Thanks for your feedback, it's very much appreciated. An elog has been added to rc7, and I think we need to extend this in some way. I feel like the gentoolkit guidexml doc could be a good point to document glsa-check in general, and fuzzyray mentioned the possibility of a glep42 news item. Either way, this needs to be addressed before getting it stable, but at this point it's too much in a flux for me to start writing docs (plus, i'm rather busy until mid september). Thanks for adding the elog, it should be enough to warn people of potential problems. (In reply to comment #2) > Either way, this needs to be addressed before getting it stable, but at this > point it's too much in a flux for me to start writing docs (plus, i'm rather > busy until mid september). Out of curiosity, are any further changes planned in glsa-check behaviour? When, more or less, is it expected to hit stable? glsa-check is included with >=sys-apps/portage-2.3.72 (bug 463952). |