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