On Sat, 16 Aug 2008 22:39:41 +0300 Petteri Räty <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > Author: Zac Medico <[EMAIL PROTECTED]> > 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
