[wpkg-users] WPKG setups.

[K.E.Jones at bton.ac.uk]

Hi Rainer,

> -----Original Message-----
> From: Rainer Meier [mailto:r.meier at wpkg.org]
> Sent: 16 March 2010 12:56
> To: Jones Keith
> Cc: wpkg-users at lists.wpkg.org
> Subject: Re: [wpkg-users] WPKG setups.
>
> Hi Keith,
>
> On 15.03.2010 23:58, K.E.Jones at bton.ac.uk wrote:
> >  I've gone back over the last 2000 or so e-mails to the list since I
was
> > here last and many people now see to use the "package" definition to
> > handle delivering a new version of software by changing the install
> > commands and "bumping" the version.
> >
> >  Is that a suggested practice nowadays?
>
> As far as I remember it has always been the suggested practice. By
> incrementing
> the package revision you instruct WPKG to perform an upgrade on
systems
> where
> the package is already applied in an older revision.
>

  Thanks for replying. As ever, your descriptions are full and very
informative.
It's good to read them and learn more :-)

  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
;-)

  I came up with a technique that fitted our workplace nicely. I guess
it's
a virtue of how flexible WPKG is that I could do things differently
without
taking too much of a hit.

  Personally, I try to keep a package definition strictly associated
with a
single version and not every version of the same package (see below).
It's
obvious that this isn't the standard approach though ;-)

>
> > I've always used the "bumping"
> > technique to update a particular package's definition. All my *real*
> > package version handling is done through profile dependencies (aka I
> > have a "Firefox" profile which depends on a "Firefox 3.5" profile
and if
> > I upgrade I change that rather than the package itself).
>
> This description is slightly confusing for me. I guess you're having a
> "Firefox
> 3.5" profile referring to a "Firefox" package. It could also be that
you
> have
> independent packages for different Firefox packages (e.g. "Firefox3"
and
> "Firefox35"). Unfortunately if you have multiple packages WPKG will
have
> to
> uninstall one if you switch to another one. But it's possible to do so
> because
> WPKG will first do all uninstall tasks and then install the new ones.
>

  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.

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

  Well, WPKG really works well in this instance :-)

  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)" />)
  b) I remove the uninstall commands from the old package and bump its
version.
  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.
  d) The new package upgrades the old package :-)

  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).
  b) WPKG goes through the whole removal and install process which is
exactly
     what I'd hope for.

  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.

  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.

  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. :-)


>
> However the usual way to do it is to use simple profiles which refer
to a
> couple
> of application packages. Only one package for each application exists
> Unless you
> want to install/update/operate multiple versions in parallel. For most
> applications this is not applicable since newer versions overwrite or
> update
> older ones. For example installing Firefox 3.5 will remove Firefox 3.5
> (respectively overwrite it). For MS Office it is possible to create an
> "office2003" and "office2007" package and apply both to the host. So
you
> can
> deploy updates or uninstall them independently.
>
> So the typical you should make sure that you have only one single
package
> defined in packages.xml (or in XML in packages/ sub folder) which
deploys
> a
> specific application. Then just always update the package definition,
> install/upgrade/downgrade/remove commands and increment the revision.
>
>
> >  I've had a problem with the "upgrade before install" option in wpkg
> > recently and I was about to bug it but I just wanted to find out if
> > things had changed before I relied on how I'm using it.
>
> This might depend on your use case. The feature has been introduced in
> order to
> simplify administration. The administrator does not have to take care
if
> the
> revision currently deployed on the client has valid uninstall commands
or
> it's
> probably broken. Admins can simply fix the package definition and make
> sure it
> just works assuming this package revision is installed. WPKG will then
> first
> make sure this version is installed before the remove takes place.
This is
> especially handy if you have a couple of clients out there and your
> package
> initially deployed does not specify any remove commands and now you
want
> to
> remove the package. If there would be no remove-before-upgrade you
would
> have to
> update the package (increment revision, add appropriate remove
commands)
> and
> then roll it out to the clients. Unfortunately for this to work you
would
> have
> to wait until the update has been rolled out. In environments where
> clients
> infrequently access the network this might take days, weeks or even
> months. Only
> after all clients got the update you would be able to remove the
package
> from
> the profile and therefore WPKG would remove the software on next sync.
> If one client missed the update to the fixed package revision it will
fail
> to
> remove the package since the revision installed on the client misses
the
> remove
> instructions.
>
> Upgrade-before-remove works around this issue. Just fix up your
package
> definition, increment the version and remove the package from the
profile.
> WPKG
> will handle the rest. Next time a client connects it's upgrading the
> application, applying new package definitions and immediately cleanly
> remove the
> software in one step.
>

  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.

  It just needs a weird person like me to be foolish enough to try to
use
it in an undocumented way. I guess it's educational though  ;-)

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

  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.

  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.

  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.

  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.

  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 :-)

 Regards,

 Keith

>
> br,
> Rainer