public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Craig Lawson <craig.lawson@alum.mit.edu>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Proposal: pre-emerge advisories
Date: Wed, 13 Jul 2005 22:24:03 -0700	[thread overview]
Message-ID: <1121318643.3180.6.camel@localhost.localdomain> (raw)

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



             reply	other threads:[~2005-07-14  5:26 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-14  5:24 Craig Lawson [this message]
2005-07-14  7:17 ` [gentoo-dev] Proposal: pre-emerge advisories Kevin F. Quinn
2005-07-14  7:36   ` Robin H. Johnson
2005-07-14  7:52     ` Georgi Georgiev
2005-07-14 14:22 ` Chris White
2005-07-18  4:32 ` [gentoo-dev] " R Hill
2005-07-23  5:34   ` Alec Warner
2005-07-23  6:04     ` Jason Stubbs
2005-07-23 13:32       ` Georgi Georgiev
2005-07-23 14:53         ` Alec Warner
2005-07-23 15:18           ` Greg KH
2005-07-25  7:51             ` Martin Schlemmer
2005-07-25 11:53               ` Jason Stubbs
2005-07-25 13:09                 ` Martin Schlemmer
2005-07-25 13:33                   ` Jason Stubbs
2005-07-25 15:26                     ` Martin Schlemmer
2005-07-25 15:27                     ` Georgi Georgiev
2005-07-26 10:31                       ` Jason Stubbs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1121318643.3180.6.camel@localhost.localdomain \
    --to=craig.lawson@alum.mit.edu \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox