Hi Keith, On 16.03.2010 20:11, k.e.jo...@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 ------------------------------------------------------------------------- wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/ _______________________________________________ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
