I use a scheme somewhat inspired by how Gentoo Linux name their packages. The packages are named like:
admin/tightvnc arch/7-zip media/vlc web/firefox web/firefox/addon/adblockplus os/winxp/kb123456 etc. Same goes for profile names that pull in the respective package(s). Some profiles exist for frequently used package combinations and default setups, most of them directly inherit from a profile "base" by depending on it. "base" in turn depends on "env" which pulls in no packages but defines variables like %SOFTWARE%. I use the original package versions as revision numbers, only adjusted should their syntax be impractical for comparisons. Should a package change without a real upgrade of the software it installs, e.g. due to changed administrative settings or fixes to the package, I append a local revision number like this for Firefox: 3.6.2 => 3.6.2-r1 - again inspired by Gentoo practise. Exceptions exist, like for MS Office I tag the major version into the package name to allow for clients with 2003 while others get 2007: office/ms-office/2003 office/ms-office/2008 Kind regards, Malte Am Mittwoch, 31. März 2010 21:43:40 schrieb donotc...@fastmail.fm: > Thanks to the WPKG wiki and the mailing list archives, I've got WPKG > basically working in a small office deployment. Thanks to the developers > for your work! > > But I'm still not clear on the best general way to manage the <package> > tags in packages.xml for smooth updates. Do you usually have the package > id & name be more generic, and just use the revision attribute to manage > version upgrade? Or do you create a new package for every patch level, > resulting in a bunch of package entries for each piece of software? > > For example, take the wiki's silent install example for Java... > > <package id="java6" name="Java Runtime Environment 6 Update 19" > revision="19" [...] > > Works easily for now, but what happens when JRE 7 comes out? Do you just > add a new "java7" package to packages.xml? Do you also remove the "java6" > package from the file? Would it be better to, instead, have something > more generic like: > > <package id="java" name="Sun JRE" revision="01061900"> > > And then just increment the revision as updates come out? > > Also what about things like the latest Adobe Reader 9.3.1 which is just a > patch? The wiki example adds the patch into the existing "adobereader93" > package entry, but doesn't that cause people who already have 9.3.0 to > have it re-installed first? Would it make more sense to put the 9.3.1 > patch into a separate package, and give it a <depends> tag pointing back > to 9.3? > > I guess i'm just looking for a rule of thumb on a consistent way to > add/modify package entries as updates come out. The examples I've seen > all vary quite a bit in their approaches and I don't know what's best. > > Thanks & sorry for the wordy post... ------------------------------------------------------------------------- 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
