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

2017-08-16 Thread Jason Zaman
On Tue, Aug 15, 2017 at 11:22:54PM -0400, Michael Orlitzky wrote: > On 08/14/2017 08:01 AM, Jason Zaman wrote: > > > > I'll give an example where revbumps are significantly inferior to > > --changed-use. > > > > ... With --changed-use, only the people who need it (ie selinux > > users) will reb

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

2017-08-16 Thread Daniel Campbell
On 08/13/2017 03:11 AM, Michael Orlitzky wrote: > On 08/12/2017 10:52 PM, Duncan wrote: >> >> How so? Are you arguing that deciding to system-wide switch to/from >> pulseaudio, systemd, or gstreamer is nonsense? >> > > The meaning of any one USE flag varies widely across packages. I could > neve

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

2017-08-16 Thread Rich Freeman
On Wed, Aug 16, 2017 at 11:56 AM, Duncan <1i5t5.dun...@cox.net> wrote: > > But even if that's the case (I wouldn't know), it's the case due to a > deliberate decision of those going "under the bus", because portage is > the default, and by choosing to use some other PM, they've deliberately > chose

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

2017-08-15 Thread Michael Orlitzky
On 08/14/2017 08:01 AM, Jason Zaman wrote: > > I'll give an example where revbumps are significantly inferior to > --changed-use. > > ... With --changed-use, only the people who need it (ie selinux > users) will rebuild and everyone is happy (selinux users because the > program now works and no

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

2017-08-14 Thread Jason Zaman
On Sat, Aug 12, 2017 at 09:05:58PM +1000, Michael Palimaka wrote: > On 08/12/2017 08:29 PM, Rich Freeman wrote: > > 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

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

2017-08-13 Thread M. J. Everitt
On 13/08/17 11:11, Michael Orlitzky wrote: > On 08/12/2017 10:52 PM, Duncan wrote: >> How so? Are you arguing that deciding to system-wide switch to/from >> pulseaudio, systemd, or gstreamer is nonsense? >> > The meaning of any one USE flag varies widely across packages. I could > never say "I wa

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

2017-08-13 Thread Michael Orlitzky
On 08/12/2017 10:52 PM, Duncan wrote: > > How so? Are you arguing that deciding to system-wide switch to/from > pulseaudio, systemd, or gstreamer is nonsense? > The meaning of any one USE flag varies widely across packages. I could never say "I want to enable USE=gstreamer" for every package i

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

2017-08-13 Thread Michael Orlitzky
On 08/12/2017 10:32 PM, Duncan wrote: >> >> What if you fix a runtime issue by dropping a flag? It's more confusing >> than it has to be: the USE flag exception interacts weirdly with all the >> other rules. > > Bad example as it's a security vuln, which requires masking/removing > vulnerable ver

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

2017-08-12 Thread Rich Freeman
On Sat, Aug 12, 2017 at 7:05 AM, Michael Palimaka wrote: > On 08/12/2017 08:29 PM, Rich Freeman wrote: >> 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 >>>

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

2017-08-12 Thread Rich Freeman
On Sat, Aug 12, 2017 at 12:22 AM, Michael Palimaka wrote: > On 08/12/2017 09:50 AM, Michael Orlitzky wrote: >> Q. But what about the rebuilds? >> >> For most packages, the rebuilds simply don't matter. Unless you're >> the maintainer of libreoffice, firefox, chromium, etc. -- just do the >>

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

2017-08-12 Thread Michael Orlitzky
On 08/12/2017 12:22 AM, Michael Palimaka wrote: > >> Q. But what if I maintain firefox, and I need to change IUSE? >> >> If the IUSE change isn't important, just make the new revision in a >> branch and wait to commit it later when there are more changes >> piled up. If it is important (lik