[wpkg-users] WPKG setups.

[Rainer Meier]

Hi  Keith,

On 16.03.2010 20:11, K.E.Jones at bton.ac.uk wrote:
>   As usual, I must be in a minority of 1 and using WPKG a bit strangely.
> In fact
> I'd probably describe my usage as exactly the reverse of common usage
> ;-)

Well, WPKG is a framework which offers package management - and like every
framework there is an intended use and millions of possible usages which were
not initially foreseen by the developer. Not necessarily a bad thing.

>   You've explained it perfectly. To be specific;
> 
>   I have "structural" profiles like;
> 
>   <profile id = "Administrative">
>         <depends profile-id = "Firefox" />
>         <depends profile-id = "Office" />
>         <depends profile-id = "Citrix" />
>     ...
>   </profile>
> 
>   and "abstract" ones like;
> 
>     <profile id = "Firefox">
>         <package package-id = "Firefox (3.5.5)" />
>     </profile>
> 
>  etc etc
> 
>   It gives me a layer of abstraction to play with and makes it easier to
> see an
> overall structure and see who's got what software from many different
> perspectives. The structural profiles act like a neat summary. The
> "abstract"
> ones give me the detail.

Well, as I thought. It's not a problem to use WPKG in this way, just be aware
what it means to your packages deployed to clients.


>   The difficulty is, as you say, "What if I want to update Firefox 3.5.x
> to 3.6?".

In this case you would have to create a new package like "Firefox (3.6)" and
assign it to the "Firefox" profile. However here I don't see your additional
level of abstraction since still you have one Firefox package assigned to the
"Administrative" profile finally.
On the other side you introduce some risks of conflicts. Let's assume somebody
adds "Firefox (3.5.5)" to the "Office" profile and assigns "Firefox (3.6)" to
the "Firefox" Profile and both are assigned to the "Administrative" profile via
dependencies. If you use uninstall checks then for sure one of the packages will
fail from WPKG point of view since there can be only one Firefox package installed.

So you just need to be careful that the resulting packages assigned to the host
are consistent.

Regarding the upgrade: For sure if you exchange your "Firefox (3.5.5)" package
with a "Firefox (3.6)" package in your "Firefox" profile, then WPKG will not do
any upgrade since "Firefox (3.6)" package is entirely new to WPKG while "Firefox
(3.5.5)" is likely to be installed on the host. So WPKG will first remove
"Firefox (3.5.5)" and then install "Firefox (3.6)".
Usually this should be no problem. However slightly inefficient and probably
prone to errors - or at least more risky to fail.
So the recommended way is to have only one single "Firefox" package and assign
this one to the "Firefox" Profile. So when you update Firefox just update the
revision number of the package and let WPKG perform an upgrade.


>   If a package *can* upgrade an older version,
> 
>   a) I create a new package, give it a suitable name and change the
> "abstract"
>      profile to use it instead. (eg <package package-id =  "Firefox
> (3.6)" />)

So far so good. Running WPKG at this point in time would make it uninstall
"Firefox (3.5.5)" and install "Firefox (3.6)" right after. Note that for WPKG
both packages are completely independent.


>   b) I remove the uninstall commands from the old package and bump its
> version.

At this point in time WPKG would (due to the update-before-remove feature) first
update to "Firefox (3.5.5)" and then remove "Firefox (3.5.5)", after this it
would install "Firefox (3.6)".
Due to the fact that the updated "Firefox (3.5.5)" package does not have any
remove commands the remove process will not perform any actions. This can become
a problem if you use package checks as well since WPKG will execute the remove
commands (none) and then it will notice that Firefox is still installed. So it
prints an error and keeps "Firefox (3.5.5)" assigned to the host.
Now on every reboot WPKG will re-try removing "Firefox (3.5.5)" which will fail
of course due to missing commands.

To exit this evil loop you could completely remove "Firefox (3.5.5)" package
from your package database. This will make WPKG to detect "Firefox (3.5.5)" as a
"zombie" and it will be removed from the local package database even if
uninstall actually fails.



>   c) WPKG goes through the removal process but the "upgrade before
> install"
>      does wonderful stuff and updates the package being removed before
>      uninstalling it. Therefore my package has all the uninstall
> commands
>      removed and leaves the package behind.

Yes it does.


>   d) The new package upgrades the old package :-)
> 
Not in case of your Firefox example. Since you've created a completely new
version of Firefox package WPKG does not know that they are somehow related.


>   If a package *cannot* upgrade an older version,
> 
>   a) I create a new package, give it a suitable name and change the
> "abstract"
>      profile to use it (as above).

This is fine, so WPKG would either uninstall the previous version first (if
removed from the abstract profile) or install both in parallel (if supported by
applications.


>   b) WPKG goes through the whole removal and install process which is
> exactly
>      what I'd hope for.

Yes it will, assuming you removed the "old" version package from the abstract
profile.
However the intended way to do such things (at least I do it like this) is to
update the package and specify some upgrade commands. Remember that you can
either refer to an upgrade-script or add multiple upgrade commands as well. The
purpose is that you might specify your first upgrade command in order to remove
any previously installed version and then the next upgrade commands are usually
identical to install commands.
So if you update your package revision then on fresh systems WPKG will just run
the install commands and on existing systems the upgrade commands will first
remove the software and then re-install the new versions.

And all done with a single package.


>   Doing it this way leaves me free to manage a single package as a
> single package
> and keep the version of the package's software separate from the
> package's
> version attribute.

Keeping the software version and package revision independently is supported
anyway. Initially WPKG only supported integer numbers in revisions - and it was
supposed to increment the revision number on each package update in order to
instruct WPKG to perform an upgrade.
Recently I've extended the revision format support in order to allow dotted (and
also some other specials) notations. For example your revision can now usually
be equal to the revision of the software. So a package revision attribute of
"3.5.5" is allowed as well as "3.6". However it's not required. Your Firefox
3.5.5 package can also use revision 1 and when you update the package to Firefox
3.6 just increment it to 2.


>   I tend to use the upgrade commands to do things that maintain this
> particular
> package (such as updating expired licenses or updating settings) rather
> than
> actually upgrading the package to a newer version.

In fact you can still do that using a single package. Just specify only your
config-file updates in update commands.


>   Basically it's a neat way of showing how useful "upgrade before
> install" can
> be :-)
> 
>   Anyway, as mentioned, I must be a bit of a lost soul in using WPKG
> this way. It
> just appeals to me as an elegant design. :-)

Well, it's fine for me if it serves your needs as you use it. Please do not
regard my explanations as an attempt to push you to change your WPKG usage. Just
keep in mind that most users (including me) are using WPKG slightly differently
and it might have some side-effects. As long as you're aware on the side-effects
you might encounter and you're aware what WPKG will do on your systems when you
change something this is fine with me.


>   I love the "upgrade before install" idea (as you can see!). I think
> it's
> actually a much more powerful concept than you've described here. Not
> only can
> it fix things up but it can actually be used strategically to make life
> even
> better. I know it was designed as a helper for administrators but I
> think it's
> actually a pretty nice feature in its own right.

Thank you. Nice to see it serves your needs. But as you can see by the config
switch to disable it and on some discussions on the mailing list not everybody
was so amazed about it.


>   The bug is that it's not comprehensive. The server copies are only
> applied
> to the packages about to be removed.

Hmm, not sure what you mean by it. If you increase the revision of a package a
regular update will be done by WPKG in any case. The upgrade-before-remove
feature just makes sure this update also takes place when a package is supposed
to be removed. Initially WPKG would just have executed the remove commands of
the package as it is stored in the local wpkg.xml file (which might be
incomplete/buggy...).


>   We have a lot of laptops that frequently go offsite for weeks (or
> months) so
> it's not unusual for me to have done lots of minor changes to things
> whilst
> they've been away.

I think this applies to lots of WPKG admins.


>   When the laptops come back on site they get updated but I often see
> installs
> failing because, not only has the package being removed been changed,
> but also
> one of its dependant packages has changed. As the dependant package
> never gets
> on the removal list independently, it never gets to have its package
> definition
> updated to the new server copy. The blockage sometimes clears and
> sometimes gets
> too complex to clear itself.

As long as you don't forget to update the revision of the dependant packages
WPKG will upgrade them too. On each WPKG /synchronize run it will go through all
packages assigned to the host (either directly or via dependencies) and check if
there is any update on them and perform the update if there is one.
The upgrade-before-remove procedure just makes sure this upgrade is applied to
package which are to be removed during this run.


>   In my case this is awkward but there's a fair chance that others have
> had the
> same issue crop up and have had to use /force or other methods to fix
> it.

Are you able to provide an example? It would be nice to know what is stored in
the local wpkg.xml of the host connecting to the network and how your
profiles/packages/host databases look like and what you expect to happen then.

By design WPKG should execute the upgrade commands on every assigned package
which has been properly updated (revision incremented).


>   I was thinking it would be nice to find a solution for this and as I
> use it
> heavily I thought I'd better make some good suggestions.

Maybe I am too tired today to follow the exact problem but from what you
describe I think WPKG should still perform the upgrades as intended (assuming
you updated the package revisions).


>   I was hoping to bug this but along with a few potential solutions but
> I could
> see so many ways of me screwing it up for others. As I haven't been
> around for
> a while I wanted to ask how people did things nowadays before I made
> assumptions
> and made an *ss out of myself :-)

I probably need more information on a specific example where it fails for you
and for which reason.
However I have to clearly say that I am not willing to sacrifice any "processing
safety" of WPKG in its "intended use" to support an uncommon use-case. But from
what I see you described I can't see a conflict right now.

br,
Rainer