On Mon, 2005-07-25 at 20:53 +0900, Jason Stubbs wrote:
> On Monday 25 July 2005 16:51, Martin Schlemmer wrote:
> > On Sat, 2005-07-23 at 11:18 -0400, Greg KH wrote:
> > > On Sat, Jul 23, 2005 at 10:53:15AM -0400, Alec Warner wrote:
> > > > Georgi Georgiev wrote:
> > > > > Just to make sure I am not missing something.
> > > > > 
> > > > > Does this cover the
> > > > > 
> > > > > - If you are upgrading from a version of udev prior to 046 ...
> > > > > - If you are upgrading from a version of udev prior to 050 ...
> > > > > - If you are upgrading from a version of udev prior to 057 ...
> > > > > - If you are upgrading from a version of udev prior to 059 ...
> > > > > 
> > > > > cases automatically? I.e. *not* showing irrelevant warnings on every
> > > > > upgrade/rebuild.
> > > > > 
> > > > 
> > > > The writer of pkg_warn() could do this, it's still in the ebuild and
> > > > could use the normal ebuild functions to determine what the user is
> > > > running ( has_version() and whatnot ) and then run a case statement on 
> > > > that.
> > > 
> > > Great, anyone care to send me a patch for the udev ebuild to do this so
> > > not everyone sees this message?  It will only get longer over time...
> > > 
> > 
> > Something like this maybe?  (Yes, I know using $T will be frowned upon,
> > but not much else you can do.  Also, might use has_version(), but that
> > is more difficult to parse, and I figured you normally only want those
> > for system udev ...)
> 
> Combining the pkg_preinst and pkg_postinst parts (and removing the usage
> of $T ;), that pretty much shows exactly what the proposed pkg_warn would
> look like. Only difference being that it would be executed before emerging
> starts.
> 

Currently:
- if everything is moved to pkg_preinst(), the message will not show at
the end of the merge, so much higher chance of getting missed.
- if everything is moved to pkg_postinst(), $udev_version will be the
new version, and be of no use.
- if you meant that this is for the pkg_warn() ... it still wont really
help that much, as it will differ from before/after the update :/


-- 
Martin Schlemmer

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to