IDEA: Update Manager (Was something to do with VMWare)



Hello people (Stop reading now if you don't like long things)

Tom Tromey brought this up when someone wanted to have a way to notify
people about new packages installed, and for them to execute various scripts
(eg, to add desktop icons). Tom's suggestion was to have a program that gets run
at the start, and lists packages that have changed since the last log on. Well I
was thinking about this, and it seemed like quite a good idea. Here are my
thoughts for people to pick apart, and if anyone doesn't have any strong
objections or compelling reasons why I shouldn't, I'll make a start to code it.

GUM: Gnome Update Manager. (Or something less crap.)

- The file format should be easily readable/writable by human and by machine so
XML is probably the best way to go about it. An example file could be
	<PACKAGE>
	    <NAME>Gnumeric</NAME>
	    <VERSION>12.5.8</VERSION>
	    <DATE>19991018</DATE>
	    <TIME>024536</TIME>
	</PACKAGE>

	<OPTION>
	    <DESCRIPTION>Installed Gnumeric</DESCRIPTION>
	    <COMMENT>Installed Gnueric. The best darn spreadsheet in the
world</COMMENT>
	</OPTION>

	<OPTION>
	    <DESCRIPTION>Add Gnueric desktop icons</DESCRIPTION>
	    <EXEC>gnumeric-add-icons.sh</EXEC>
	    <GID type="exclude">third-year</GID>
	    <UID type="exclude">iain, bob</UID>
	    <UID type="include">dave, phil, steve</UID>
	    <COMMENT>Adds icons to the GNOME desktop, to run Gnumeric</COMMENT>
	</OPTION>

- The items in <OPTION></OPTION> are displayed on a clist or ctree. The user 
could select what options they want to run and then click okay, and the program 
would run the relevant <EXEC></EXEC> for that option.

- The <GID> and <UID> tags take attributes type which can be either "include" or
"exclude" that tells the program what users would be able to run which options.
The complicated bit with this is that the tag works on the set of users from 
the line before. If the first tag is type "exclude" then the initial set is the
set of all users, if the first tag is type "include" then the initial set is the
empty set.
For example: If the group third-year contains users Dave, Al and Steve and the
group fourth-year contains Iain, Georges and Paul then the lines
	<GID type="exclude">third-year</GID>
	<UID type="include">Al</UID>
would mean that Iain, Georges, Paul and Al would be able to see those options,
but Dave and Steve would not, and the lines
	<UID type="include">Georges, Al</UID>
would allow Al and Georges to see the options.

- The <COMMENT> tag could also take 2 attributes include and exclude to allow
personalised comments.
	<COMMENT exclude="iain,al">Iain and Al can't see this</COMMENT>
	<COMMENT include="iain">A comment for Iain</COMMENT>
	<COMMENT include="al">Al's comment</COMMENT>

- The file could also supply the MOTD.

- Each package would install all it's necessary scripts in
$(share)/gum/PACKAGENAME/ and also the script (package.gum?) so the
<EXEC></EXEC> commands would be local to that directory.

The client.
- The client would load the timestamp of the last time it was run, then stat the
.gum files in the directories to discover what has been installed since the last
time.

- It would display the options in a CList/CTree and the user could select what
options he/she wants to install, and click OK, and the relevant scripts would 
be run. The time would then be stored to file again and the client would close.

- Client options include 
	- "Email me the notices" in which it would parse the relevant files, 
	and construct an email that would be sent and the user would not even 
	see a window opening.
	- "Run everytime" would mean that the client would add itself to the
	session manager.
	- "Never run" would mean that the client would only run when the user
	ran the program explicitly.

- There would also be a "Remind me next time" button, for if the user just wants
to quickly log on, and read emails or get a file, and doesn't want hassle. In
this case the client would just quit and not update the timestamp.

Hmm, that's a lot longer than I meant, sorry about that.
That was my thoughts about an update manager, so like I said, all comments are
welcome, and I'll code this if no-one has any objections or thinks that it's
just a bit too much overkill.

If you got here, I think you deserve a prize, but I don't have any, so you can't
have one.

iain



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