Re: [gentoo-dev] Proposal: pre-emerge advisories

[Georgi Georgiev]

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 (craig.lawson@××××××××.edu) 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        *>
<*    chutz@×××.net    <* light fails to shine, but because people     <*
*>  [phone]   *> refuse to see it. -- James Michener,         *>
<* ------------------- <* "Space"                                      <*