[Yum] Weird wish

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2 Mar 2005, Michael Stenner wrote:

> On Wed, Mar 02, 2005 at 03:05:28PM -0500, seth vidal wrote:
> > 1. it's a slippery slope in terms of what you include in such a message
> > 2. it'd be better to include a generic 'repository info url' in the
> > repodata that could be used for any/all information.
> 
> Yes, MOTD is tough.  I'm betting most of the people rarely run yum
> directly, so they may very well rarely see it anyway.  Also, does yum
> force it down your throat?  Personally, I sometimes like an MOTD (if
> it's informative and helpful) but normally they just annoy me.  Would
> yum let you turn it off?  Would it just be at some output level?

In the "more than one way to do things" philosophy of computers, one
MIGHT be able to create a trivial rpm such as yum_announce.noarch.rpm
and make it a universal dependency.  yum_announce could then "do the
right thing" -- presumably anything from put a trivial %post message on
the screen (and then nothing) to feed a message to mail (to root), to
logger, to a popup display program.

This of course puts the onus of motd wrapping on the repository owner
that thinks it necessary.  And it might require a bit of trickery to get
yum to "install" or "update" it on any use.

Supporting this latter -- which is basically an rpm pull/push mechanism
-- seems like a better and more generally useful yum feature to consider
than motd per se.  If one could easily make any specific rpm(s) a
"universal dependency" of all rpm's, then this would work, and it would
also facilitate the ability to automagically install e.g. emergency
security packages on remote systems whether or not they were already
installed.  That is, the real question is whether or not yum
repositories (or rather their managers) should have >>a<< mechanism to
perform a "push" to a client of an arbitrary rpm to accompany its next
update/"pull" of any rpm.

I personally wouldn't be comfortable with this unless a client could
turn it off, but one COULD always add a push<=>[yes,no] binary flag to
repository config files on the client side.  If a user wanted to (and
knew how) they could then turn this off, but it would leave primary
control of the ability in the people setting up the repository and its
default repo configs, so a repo manager could turn it on or off for all
repo users by default.  I can definitely think of times where this would
be useful to essential to e.g. campus security managers...

That seems like a lot more useful a capability than MOTD per se -- it
would enable an motd push as one of the least of its uses. 

Come to think of it, one could probably implement a poor-man's version
of this without modifing yum at all.  Pick any essential but totally
stable package in Base (e.g.  setup, which distributes /etc/motd and so
forth).  Add your %post script there.  To display an motd type message,
edit %post and bump the rev number.  It wouldn't necessarily pop up on
an arbitrary install, but it would be caught by any generic update.

But I kinda like the idea of a controllable rpm push facility.

    rgb

> 
> This leads me to the more general question (which I'm exploring purely
> out of intellectual curiosity, and NOT suggesting new features) of
> communication between repo and client.  Lets say, for example that you
> wanted to very politely say "look y'all, you need to find a new repo"
> and make yours unavailable to them.  There's currently no way to
> communicate a fairly yum-specific message.  The best you could do is
> make things inaccessible and then put up a web page hoping folks would
> find it.  Seth's idea would address most of this.
> 
> 					-Michael
> 
> 

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb@xxxxxxxxxxxx



[Index of Archives]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux