[wpkg-users] Newbie question: Package Naming Best Practices? [SEC=UNOFFICIAL]

[Michael Chinn]

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.chinn at 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-bounces at lists.wpkg.org [mailto:wpkg-users-bounces at lists.wpkg.org] On Behalf Of Malte Starostik
Sent: 01 April 2010 07:23
To: wpkg-users at 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 donotcare at 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 at lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users