I too struggle with naming packages in a consistent manner, I like your schema I am guessing this would be the summary...
category[-productsuite][-addon]-product[-majorversion] I have added one amendment from my own system category[-productsuite][-addon|fix|remove|settings]-product[-majorversion] (basically Im just adding a verb to sub-products) I can see this being pretty useful to enforce once you get past 20-30 packages (Im at 210, sigh!) A wiki policy/best practice page might be useful for things like this. Michael Chinn PC Support Office Information and Communications Technology Great Barrier Reef Marine Park Authority 2-68 Flinders Street PO Box 1379 Townsville Qld 4810 Ph: 07 4750 0855 Fax: 07 4772 6093 email: michael.ch...@gbrmpa.gov.au Visit us at: http://www.gbrmpa.gov.au ============================================================================= If you have received this transmission in error please notify us immediately by return email and delete all copies. Any unauthorised use, disclosure or distribution of this email is prohibited. ============================================================================= -----Original Message----- From: wpkg-users-boun...@lists.wpkg.org [mailto:wpkg-users-boun...@lists.wpkg.org] On Behalf Of Malte Starostik Sent: 01 April 2010 07:23 To: wpkg-users@lists.wpkg.org Subject: Re: [wpkg-users] Newbie question: Package Naming Best Practices? 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 ------------------------------------------------------------------------- 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
