maillog: 14/07/2005-00:36:15(-0700): Robin H. Johnson types > On Thu, Jul 14, 2005 at 09:17:38AM +0200, Kevin F. Quinn wrote: > > On 14/7/2005 7:24:03, Craig Lawson ([EMAIL PROTECTED]) wrote: > > > [...] To be more concrete, I'm thinking of something like a database [...] > > I don't think a separate database is a good idea; too many sources for > > information. > How about using metadata.xml? I'd think this data is ideally suited for > it. It's metadata about the package, and it's already distributed with > the tree. > > > > [...] For example [...] > > > 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... > > > > How about adding: > > > > ADVICE="Menu editing disabled until follow-up release. > > Work-around is to install Python 4 + smeg. See > > forum topic http://forums.gentoo.org/blah..."; > > > > to the gnome-menus-2.10.0 ebuild (sorry Chris, no parsing needed :} ). > > It'd be trivial to knock up a widget to extract and display this data, > > and I'd guess trivial to add an '--advice' option to emerge to do the > > same. Perhaps it'd be simpler just to include it alongside the > > changelog data with the '--changelog' option. > Putting it in the ebuild becomes a bit complex when you want to include > lots of text, or if you want to display a message for a specific > downgrade or something else like that. Basically while you have the > 'target' attribute, you have no way to specify the 'current' attribute, > and you can't have multiple advisories per ebuild. > > metadata.xml variant: > <pkgmetadata><advisory target="=gnome-base/gnome-menus-2.10.0"> > Menu editing disabled until follow-up release. > Work-around is to install Python 4 + smeg. See > forum topic http://forums.gentoo.org/blah... > </advisory></pkgmetadata> > ('current' attribute defaulting to any version, and both the 'target' > and 'current' attributes should be full package atoms.) > > > Of course such advice could be just written into the changelog in the first > > place... > The problem is that users complain and don't read the changelog, since > it's too long. They want only specific advisories that are needed, not > every little change notice.
Since the changelog was mentioned, and since there is already a --changelog switch (that I don't use because of the above-stated reason), maybe some changelog entries could be marked as having a higher priority (somehow reminds me of einfo and ewarn). If it were possible to omit the "info" level entries and only show the important stuff from the changelog with --changelog it would have been really useful. emerge --changelog=warn ;) There is no need for "current" or "target" either, since --changelog already does the parsing. -- *> Georgi Georgiev *> An age is called Dark not because the *> <* [EMAIL PROTECTED] <* light fails to shine, but because people <* *> +81(90)2877-8845 *> refuse to see it. -- James Michener, *> <* ------------------- <* "Space" <*
pgpzXbG3VoDoW.pgp
Description: PGP signature
