Re: [gentoo-dev] News item: World file handling changes in Portage-2.2

[Marius Mauch]

On Sat, 16 Aug 2008 22:39:41 +0300
Petteri Räty <betelgeuse@g.o> wrote:

> As per glep 42 (http://www.gentoo.org/proj/en/glep/glep-0042.html)
> here is the required email for a new news item. This news item is
> important because otherwise users will be missing updates to the
> system set if they continue updating their system with the usual
> emerge --update
> --deep world. Unless objections come out the new news item will be
> committed at the same time as rc8 (rc8 will have an update man
> portage page describing world_sets).
>
> Title: World file handling changes in Portage-2.2
> Author: Petteri Räty <betelgeuse@g.o>
> Author: Zac Medico <zmedico@g.o>
> Content-Type: text/plain
> Posted: 2008-XX-XX
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: >sys-apps/portage-2.2_rc8
>
> As of Portage 2.2 the world set does not include the system
> set any more. If you want emerge --update --deep @world to
> update the system set too, you need to add @system to the new
> world_sets file in /var/lib/portage/. For more information on
> world_sets see man portage.

Sorry for not replying earlier, I was without mail access for the last
few weeks.

First, regarding the news item, I'd suggest that instead of telling
users to modify world_sets manually to use `emerge --noreplace @system`.
Also there have been more changes that might not be as obvious and only
affect people with "unusual" usage patterns, namely `emerge @world`
without using --update or --noreplace will rebuild packages contained
in @world (same is true for all other sets).

Second for the suggestions on how to handle the transition:
- treating 'world' and '@world' differently is a no go from my POV. One
of the main reasons to implement them as sets was to remove special
case code in emerge, so I'm quite opposed to adding new special cases
instead. And I'm quite sure that such a separation would cause
confusion, and some isues regarding (end-user) documentation.
- adding a new @worldfile set to get the new behavior, and use @world
for the old. That one is quite interesting, and should actually
be rather simple to implement: rename the existing @world to
@worldfile, create a new StaticFileSet @world that just contains
@worldfile and @system (stored in /usr/share/portage), change most
references in emerge from @world to @worldfile (for technical reasons,
the WorldSet class is somewhat special), and add world-candidate=False
to the default sets.conf
- issuing a warning if 'world' is the only argument would also be a
special case, but by far not as invasive as the first suggestion. I've
actually considered to mark 'world' and 'system' without the set prefix
as deprecated but thought it would be too invasive/annoying at this
time.
- another idea that hasn't been mentioned yet is that we could simply
inject @system into world_sets in the portage ebuild when we detect a
2.1->2.2 upgrade (the ebuild already does a few other migrations that
way). That would be the least-invasive way to keep the old behavior,
but only works for poeple who haven't upgraded to 2.2 yet (not sure if
that's a pro or contra)

Though honestly I don't think this issue is as big as some other
people make it. People might miss some updates. The same would happen
if we remove packages from @system, or people switch profiles (so
@system changes).

Marius