| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
This would complicate tab completion if not done correctly. |
| 5 |
Perhaps a /usr/portage/ebuilds/ directory containing everything, and then |
| 6 |
symlinks in category directories... but as someone else pointed out, CVS |
| 7 |
lacks symlink support... Can anyone come up with a similar idea which doesn't |
| 8 |
make tab-completion too difficult (bash-completion could be used in some, but |
| 9 |
not all cases)? |
| 10 |
|
| 11 |
On Saturday 06 September 2003 01:50 am, Thomas de Grenier de Latour wrote: |
| 12 |
> Just to make it clear, I also think a tree reorganisation is needed and |
| 13 |
> there has been some good ideas here (my preference goes to the flat |
| 14 |
> repository with multiple informative categories inside ebuilds, as |
| 15 |
> proposed by Jean Jordaan). My point is only that this is something that |
| 16 |
> has to be thought early enough to avoid forgeting any user when it |
| 17 |
> comes real. |
| 18 |
> |
| 19 |
> |
| 20 |
> On Sat, 6 Sep 2003 00:17:29 +0000 |
| 21 |
> |
| 22 |
> Luke-Jr <luke-jr@g.o> wrote: |
| 23 |
> > Would it be possible to require a real user to run the 'emerge world' |
| 24 |
> > and say "yes" to a question? |
| 25 |
> |
| 26 |
> If "emerge world" still works after the tree reorganisation, then there |
| 27 |
> is no backward compatibility issue. But it doesn't seem so obvious to |
| 28 |
> me: with many of the solution suggested so far, a current portage would |
| 29 |
> not even pass the dep caching that comes after the sync. |
| 30 |
> |
| 31 |
> > If stdin cannot be opened (cron job), send root@localhost a mail. |
| 32 |
> |
| 33 |
> Doesn't change the fact that the best a current version portage can do |
| 34 |
> is to inform you that a new version is available. If I do my next sync |
| 35 |
> in six month in my 486 gateway because of a new openssh bug, I shouldn't |
| 36 |
> be blocked only because I've ignored this information. |
| 37 |
> |
| 38 |
> > Having two trees would require every package change to be done on each |
| 39 |
> > tree... Just as complex, I'd think. |
| 40 |
> |
| 41 |
> There would be no need to maintain the old tree, but only to keep |
| 42 |
> something that is enough for people to make the transition (at least |
| 43 |
> new portage and his deps). This plus a mechanism to force portage |
| 44 |
> upgrade when really needed would be enough. |
| 45 |
|
| 46 |
- -- |
| 47 |
Luke-Jr |
| 48 |
Developer, Gentoo Linux |
| 49 |
http://www.gentoo.org/ |
| 50 |
-----BEGIN PGP SIGNATURE----- |
| 51 |
Version: GnuPG v1.2.3 (GNU/Linux) |
| 52 |
|
| 53 |
iD8DBQE/WUCDZl/BHdU+lYMRAv5/AJoCwUkshITwvDf+jAHq08gFmwsR7ACeI+HO |
| 54 |
DtNX7VsdbL6mX0i8B63OAsI= |
| 55 |
=vFiV |
| 56 |
-----END PGP SIGNATURE----- |
| 57 |
|
| 58 |
|
| 59 |
-- |
| 60 |
gentoo-dev@g.o mailing list |
Archives