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

["Michał Górny" <mgorny@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 4133 bytes --]

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 benefit from some
> hindsight. Specifically, the PR says that it's OK to change IUSE without
> creating a revision, because users can use --changed-use to catch it.
> My immediate objection to that was that --changed-use is specific to
> Portage, but let's reflect on the status quo.
> 
> 
> == The situation now ==
> 
>   1 We tell everyone to update with either --newuse or --changed-use.
> 
>   2 Developers change IUSE without new revisions.
> 
>   3 To facilitate (1) and (2), Portage has the --changed-use and
>     --newuse flags. Paludis has a family of "--keep" options to avoid
>     reinstallation, e.g. --keep=if-same-metadata. And pkgcore has its
>     own (different) --newuse flag.
> 
>   4 There is no specification for the features in (3), and each package
>     manager has taken a different approach.
> 
> 
> The end result is that Portage users do see the changes made to IUSE
> without a revision, but at a cost:
> 
>   * They have to pass the "required" --changed-use or --newuse flags to
>     every command.
> 
>   * The same cannot be said for users of other package managers.
> 
>   * Lots of PM code exists to handle this stuff.
> 
>   * Our documentation needs to describe the above (relatively)
>     complicated situation.
> 
> 
> And with one notable benefit:
> 
>   * We don't need to rename the ebuild to change IUSE, and in theory we
>     can control when rebuilds happen.
> 
> 
> 
> == 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
>     friends.
> 
>   * The documentation becomes much simpler: revbump if IUSE changes.
> 
>   * Users can omit --newuse and --changed-use from their lives.
> 
>   * All package managers now handle IUSE changes properly.
> 
>   * emerge runs a bit faster.
> 
> This has none of the downsides of the current approach. Of course, it
> lacks that one benefit -- that you don't have to rename the ebuild when
> you change IUSE. Now I'll try to convince you that the rename and
> associated rebuilds aren't that big of a deal.
> 
> 
> 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
>   revision and forget about the (quick) rebuilds.
> 
>   We tell everyone to use --changed-use and --newuse if they want
>   things to work, so they were probably going to rebuild anyway.
> 
> 
> 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 (like if its default value changes
>   RDEPEND), then it would have required a revision anyway.
> 
> 
> Q. But I work on a team, and we can't all work in different branches.
> 
>   If you work on a massive package and if you're collaborating with
>   others regularly, you can commit the new ebuild masked. This is
>   annoying, but is an extremely rare combination of circumstances.
> 
> 
> == 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 get simpler, documentation gets simpler, the user
> interface gets simpler, and behavior becomes more uniform and predictable.
> 
> Please let me know what you think.
> 

Please provide some examples of recent in-place USE changes that benefit
from revbumps.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 988 bytes --]