[wpkg-users] Newbie question: Package Naming Best Practices? [SEC=UNOFFICIAL]
Michael.Chinn at gbrmpa.gov.au
Thu Apr 1 03:06:38 CEST 2010
I too struggle with naming packages in a consistent manner, I like your schema
I am guessing this would be the summary...
I have added one amendment from my own system
(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.
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.
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:
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:
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
More information about the wpkg-users