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 automatically gets ~ ke
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 issue that I think can
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 happens routinely as n
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 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
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, no
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 use.stable.mask
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,
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
> come with a new
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
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 p
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.
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 not
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 b
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 position
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 o
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 doesn
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.
>
Do
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
> frien
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 benefit from some
hindsight. Specifically, the PR says that it's OK to c
20 matches
Mail list logo