1 |
This past weekend, I upgraded about 80 packages and a kernel and later |
2 |
discovered that my CD-ROM drive went missing and my lovingly crafted |
3 |
gnome menus were trashed by Gnome 2.10 and no longer editable. Oh joy, |
4 |
another portage upgrade surprise. Some rummaging around in the Gentoo |
5 |
forums sent me in the right direction and the CD-ROM was handily fixed. |
6 |
But the menus were more complicated and I reverted Gnome. |
7 |
|
8 |
Not the first time this has happened. Friends, I won't bore you with |
9 |
tales of my past singeing, as I sense your hand itching towards your |
10 |
Flame On! button. Instead, I have a proposal for discussion. |
11 |
|
12 |
What I'd like to see *before* I upgrade is a list of advisories about |
13 |
what trouble I'm in for. By the time most people upgrade a package, |
14 |
someone's been there before and felt the pain. The answers, or at least |
15 |
the warnings, are in the Forums. Yet searching the forums before |
16 |
upgrading each package is not practical. Similarly, the build logs are |
17 |
99% stuff I don't care to read and 1% that I really do. How to find it? |
18 |
Better yet, I'd like to see it *before* I build. |
19 |
|
20 |
Currently that stuff comes from each ebuild's post-install procedure, |
21 |
however I don't think that's the best place for it: it's not easy to |
22 |
change or amend (gotta be the package maintainer), it's risky to change |
23 |
(too easy to introduce a syntax error), and it isn't specific to |
24 |
individual situations. |
25 |
|
26 |
To be more concrete, I'm thinking of something like a database with |
27 |
three entries per record: current package+version, target package |
28 |
+version, and some advisory text. For example, a few useful entries |
29 |
would be: |
30 |
current: any |
31 |
target: =gnome-base/gnome-menus-2.10.0 |
32 |
advisory: Menu editing disabled until follow-up release. |
33 |
Work-around is to install Python 4 + smeg. See |
34 |
forum topic http://forums.gentoo.org/blah... |
35 |
and: |
36 |
current: <sys-fs/udev-60 |
37 |
target: >=sys-fs/udev-60 |
38 |
advisory: Rules file changed syntax. Preserve old rules file |
39 |
and be prepared to rewrite. |
40 |
and: |
41 |
current: <kernel/vanilla-sources-2.6.11.11 |
42 |
target: =kernel/vanilla-sources-2.6.11.11 |
43 |
advisory: ide-cd no longer loaded by default. Add to |
44 |
/etc/modules.autoload/kernel2.6 |
45 |
|
46 |
and when emerge figures out what it's going to build, the "--advise" |
47 |
option (let's say) tells it to consult the database and issues a report. |
48 |
Simple as that. |
49 |
|
50 |
The database could be hosted on a Gentoo server, though it might be |
51 |
better delivering it along with the "emerge sync" data and have the |
52 |
build machine do all the work. Data could be stored in a single file, or |
53 |
distributed throughout /usr/portage as ebuilds are. |
54 |
|
55 |
Regardless of implementation, the main goals are: |
56 |
1. Adding or modifying advisories is relatively easy. Doesn't require |
57 |
programming skills. |
58 |
2. Adding an advisory in no way risks an ebuild file. An ebuild is |
59 |
executable code and no one has time to chase down syntax errors. |
60 |
Advisories are separate. |
61 |
3. You don't need to be the package maintainer to do it (though at this |
62 |
point I'm not sure who would -- maybe a collaboration of forum |
63 |
moderators and package maintainers?). |
64 |
|
65 |
Comments? |
66 |
|
67 |
Best Regards, |
68 |
Craig. |
69 |
|
70 |
|
71 |
-- |
72 |
gentoo-portage-dev@g.o mailing list |