| 1 |
Just to make it clear, I also think a tree reorganisation is needed and |
| 2 |
there has been some good ideas here (my preference goes to the flat |
| 3 |
repository with multiple informative categories inside ebuilds, as |
| 4 |
proposed by Jean Jordaan). My point is only that this is something that |
| 5 |
has to be thought early enough to avoid forgeting any user when it |
| 6 |
comes real. |
| 7 |
|
| 8 |
|
| 9 |
On Sat, 6 Sep 2003 00:17:29 +0000 |
| 10 |
Luke-Jr <luke-jr@g.o> wrote: |
| 11 |
|
| 12 |
> Would it be possible to require a real user to run the 'emerge world' |
| 13 |
> and say "yes" to a question? |
| 14 |
|
| 15 |
If "emerge world" still works after the tree reorganisation, then there |
| 16 |
is no backward compatibility issue. But it doesn't seem so obvious to |
| 17 |
me: with many of the solution suggested so far, a current portage would |
| 18 |
not even pass the dep caching that comes after the sync. |
| 19 |
|
| 20 |
> If stdin cannot be opened (cron job), send root@localhost a mail. |
| 21 |
|
| 22 |
Doesn't change the fact that the best a current version portage can do |
| 23 |
is to inform you that a new version is available. If I do my next sync |
| 24 |
in six month in my 486 gateway because of a new openssh bug, I shouldn't |
| 25 |
be blocked only because I've ignored this information. |
| 26 |
|
| 27 |
> Having two trees would require every package change to be done on each |
| 28 |
> tree... Just as complex, I'd think. |
| 29 |
|
| 30 |
There would be no need to maintain the old tree, but only to keep |
| 31 |
something that is enough for people to make the transition (at least |
| 32 |
new portage and his deps). This plus a mechanism to force portage |
| 33 |
upgrade when really needed would be enough. |
| 34 |
|
| 35 |
-- |
| 36 |
TGL. |
| 37 |
|
| 38 |
-- |
| 39 |
gentoo-dev@g.o mailing list |
Archives