Re: [gentoo-dev] Revisions for USE flag changes

On Sun, 13 Aug 2017 12:12:39 -0400 Michael Orlitzky wrote: > On 08/13/2017 12:06 PM, William Hubbs wrote: > > > > There is a down side you didn't talk about -- more work for the arch > > teams and for us in terms of stabilizations. > > > > When we revbump, a new revision

Re: [gentoo-dev] Revisions for USE flag changes

On Fri, 11 Aug 2017 19:50:14 -0400 Michael Orlitzky wrote: > We have a pull request for the devmanual that will update the revision > documentation; namely, when to create a new one: > > https://github.com/gentoo/devmanual.gentoo.org/pull/67 > > The comments bring up an

Re: [gentoo-dev] Revisions for USE flag changes

On Aug 13, 2017 6:38 AM, "Michael Orlitzky" wrote: On 08/13/2017 01:01 AM, Hans de Graaff wrote: > On Sat, 2017-08-12 at 05:58 -0400, Michael Orlitzky wrote: >> >> I simply overlooked the global USE change in make.conf because IMO >> it's a nonsense operation. > > This also

Re: [gentoo-dev] Revisions for USE flag changes

On 08/13/2017 12:06 PM, William Hubbs wrote: > > There is a down side you didn't talk about -- more work for the arch > teams and for us in terms of stabilizations. > > When we revbump, a new revision automatically gets ~ keywords on all arches > unless we make an exception. If a revision

Re: [gentoo-dev] Revisions for USE flag changes

On Fri, Aug 11, 2017 at 07:50:14PM -0400, Michael Orlitzky wrote: > == tl;dr == > > We would be better off with respect to IUSE changes and revisions if we > deleted the --changed-use and --newuse flags right now, and just > required developers to revbump when changing IUSE. > > Package managers

Re: [gentoo-dev] Revisions for USE flag changes

On 08/13/2017 01:01 AM, Hans de Graaff wrote: > On Sat, 2017-08-12 at 05:58 -0400, Michael Orlitzky wrote: >> >> I simply overlooked the global USE change in make.conf because IMO >> it's a nonsense operation. > > This also happens routinely as new python and ruby versions are marked > stable,

Re: [gentoo-dev] Revisions for USE flag changes

On Sat, 2017-08-12 at 05:58 -0400, Michael Orlitzky wrote: > > I simply overlooked the global USE change in make.conf because IMO > it's > a nonsense operation. This also happens routinely as new python and ruby versions are marked stable, not via make.conf, but by removing their

Re: [gentoo-dev] Revisions for USE flag changes

On 08/12/2017 06:29 AM, Rich Freeman wrote: > > My gut feeling is that the change you want is probably a good thing, > but it will never happen if you can't provide a single example of > something bad happening due to the lack of a revbump. There's an unfixed security vulnerability with USE=foo,

Re: [gentoo-dev] Revisions for USE flag changes

On Sat, Aug 12, 2017 at 5:57 AM, Michael Orlitzky wrote: > On 08/12/2017 03:03 AM, Michał Górny wrote: >> >> Please provide some examples of recent in-place USE changes that benefit >> from revbumps. >> > > There is no single example. Things only get simpler if *all* USE changes

Re: [gentoo-dev] Revisions for USE flag changes

On 08/12/2017 11:57 AM, Michael Orlitzky wrote: > There is no single example. Things only get simpler if *all* USE changes > come with a new revision. IMO every significant(*) change should yield into a revision bump. (*) == comments and echo arguments changes are not significantly, all others

Re: [gentoo-dev] Revisions for USE flag changes

On 08/12/2017 04:39 AM, Paweł Hajdan, Jr. wrote: >> >> The option is the same as --newuse except it ignores functionality that >> you suggest to remove. You could certainly deprecate one option or the >> other if they became the same. But the core functionality of >> system-wide USE changes (by

Re: [gentoo-dev] Revisions for USE flag changes

On 08/12/2017 03:03 AM, Michał Górny wrote: > > Please provide some examples of recent in-place USE changes that benefit > from revbumps. > There is no single example. Things only get simpler if *all* USE changes come with a new revision.

Re: [gentoo-dev] Revisions for USE flag changes

On 12/08/2017 03:11, Brian Evans wrote: > --changed-use (-U) >Tells emerge to include installed packages where USE flags have >changed since installation. This option also implies the >--selective option. Unlike --newuse, the --changed-use option >does

Re: [gentoo-dev] Revisions for USE flag changes

On pią, 2017-08-11 at 19:50 -0400, Michael Orlitzky wrote: > We have a pull request for the devmanual that will update the revision > documentation; namely, when to create a new one: > > https://github.com/gentoo/devmanual.gentoo.org/pull/67 > > The comments bring up an issue that I think can

Re: [gentoo-dev] Revisions for USE flag changes

On Fri, 2017-08-11 at 19:50 -0400, Michael Orlitzky wrote: > > == New revisions for USE flag changes == > > I suggest that in hindsight, we can do better. Not all IUSE changes are equal and thus a policy that treats them all the same doesn't make sense to me. Maintainers are in a better

Re: [gentoo-dev] Revisions for USE flag changes

On 08/11/2017 08:59 PM, Michael Orlitzky wrote: > On 08/11/2017 08:45 PM, Brian Evans wrote: >> >> I disagree about removing --newuse and --changed-use from portage. >> This is not their only use. >> >> If you happen to change the effective use system wide, USE= in make.conf >> for portage, these

Re: [gentoo-dev] Revisions for USE flag changes

On 08/11/2017 08:59 PM, Michael Orlitzky wrote: > > Does --changed-use help there? I can see the argument for --newuse, but > I thought --changed-use only applied to flags that were added or removed > to installed packages (which becomes impossible, if we require new > revisions). > ^ this

Re: [gentoo-dev] Revisions for USE flag changes

On 08/11/2017 08:45 PM, Brian Evans wrote: > > I disagree about removing --newuse and --changed-use from portage. > This is not their only use. > > If you happen to change the effective use system wide, USE= in make.conf > for portage, these options scan the entire system for such changes. >

Re: [gentoo-dev] Revisions for USE flag changes

On 08/11/2017 07:50 PM, Michael Orlitzky wrote: > == New revisions for USE flag changes == > > I suggest that in hindsight, we can do better. Suppose we require a new > revision for every change to IUSE. Then, > > * We can delete all of the PM code for --changed-use and --newuse and >