1 |
On Sat, 16 Aug 2008 22:39:41 +0300 |
2 |
Petteri Räty <betelgeuse@g.o> wrote: |
3 |
|
4 |
> As per glep 42 (http://www.gentoo.org/proj/en/glep/glep-0042.html) |
5 |
> here is the required email for a new news item. This news item is |
6 |
> important because otherwise users will be missing updates to the |
7 |
> system set if they continue updating their system with the usual |
8 |
> emerge --update |
9 |
> --deep world. Unless objections come out the new news item will be |
10 |
> committed at the same time as rc8 (rc8 will have an update man |
11 |
> portage page describing world_sets). |
12 |
> |
13 |
> Title: World file handling changes in Portage-2.2 |
14 |
> Author: Petteri Räty <betelgeuse@g.o> |
15 |
> Author: Zac Medico <zmedico@g.o> |
16 |
> Content-Type: text/plain |
17 |
> Posted: 2008-XX-XX |
18 |
> Revision: 1 |
19 |
> News-Item-Format: 1.0 |
20 |
> Display-If-Installed: >sys-apps/portage-2.2_rc8 |
21 |
> |
22 |
> As of Portage 2.2 the world set does not include the system |
23 |
> set any more. If you want emerge --update --deep @world to |
24 |
> update the system set too, you need to add @system to the new |
25 |
> world_sets file in /var/lib/portage/. For more information on |
26 |
> world_sets see man portage. |
27 |
|
28 |
Sorry for not replying earlier, I was without mail access for the last |
29 |
few weeks. |
30 |
|
31 |
First, regarding the news item, I'd suggest that instead of telling |
32 |
users to modify world_sets manually to use `emerge --noreplace @system`. |
33 |
Also there have been more changes that might not be as obvious and only |
34 |
affect people with "unusual" usage patterns, namely `emerge @world` |
35 |
without using --update or --noreplace will rebuild packages contained |
36 |
in @world (same is true for all other sets). |
37 |
|
38 |
Second for the suggestions on how to handle the transition: |
39 |
- treating 'world' and '@world' differently is a no go from my POV. One |
40 |
of the main reasons to implement them as sets was to remove special |
41 |
case code in emerge, so I'm quite opposed to adding new special cases |
42 |
instead. And I'm quite sure that such a separation would cause |
43 |
confusion, and some isues regarding (end-user) documentation. |
44 |
- adding a new @worldfile set to get the new behavior, and use @world |
45 |
for the old. That one is quite interesting, and should actually |
46 |
be rather simple to implement: rename the existing @world to |
47 |
@worldfile, create a new StaticFileSet @world that just contains |
48 |
@worldfile and @system (stored in /usr/share/portage), change most |
49 |
references in emerge from @world to @worldfile (for technical reasons, |
50 |
the WorldSet class is somewhat special), and add world-candidate=False |
51 |
to the default sets.conf |
52 |
- issuing a warning if 'world' is the only argument would also be a |
53 |
special case, but by far not as invasive as the first suggestion. I've |
54 |
actually considered to mark 'world' and 'system' without the set prefix |
55 |
as deprecated but thought it would be too invasive/annoying at this |
56 |
time. |
57 |
- another idea that hasn't been mentioned yet is that we could simply |
58 |
inject @system into world_sets in the portage ebuild when we detect a |
59 |
2.1->2.2 upgrade (the ebuild already does a few other migrations that |
60 |
way). That would be the least-invasive way to keep the old behavior, |
61 |
but only works for poeple who haven't upgraded to 2.2 yet (not sure if |
62 |
that's a pro or contra) |
63 |
|
64 |
Though honestly I don't think this issue is as big as some other |
65 |
people make it. People might miss some updates. The same would happen |
66 |
if we remove packages from @system, or people switch profiles (so |
67 |
@system changes). |
68 |
|
69 |
Marius |