Message: previous - next
Month: November 2012

Re: [trinity-devel] Package naming

From: Darrell Anderson <humanreadable@...>
Date: Tue, 13 Nov 2012 12:36:55 -0800 (PST)
> One of the points for discussion in R14 Road Map is the question about
> naming packages. I suppose it is beyond dispute that in the name of
> packages should be 'trinity' (or perhaps 'tde'?). Other issues for
> decision I would see the following:
> 1. 'trinity' before name or after? Or leave it distribution specific?
> 2. How to mark development version of packages? What about 14.0.0~preXXX?
> For example: + amarok-trinity_14.0.0~pre148.orig.tar.xz
> amarok-trinity_14.0.0~pre148-0debian11+pr16~squeeze...
> + amarok-trinity-14.0.0~pre148-i486-13.1_1.txz
> Note0: Because the Debian / Ubuntu version number must begin with a digit,
> it is impossible packages with the version number beginning with the
> letter 'R'. Therefore, such a question was unnecessary.
> Note1: I am aware that it is not currently possible to change the version
> numbers of packages in nightly-builds. But I want to have arranged rules
> to marking package versions before beta / RC versions, and before moving
> nightly-builds to target version 14.1.0.

My thoughts:

1. Let's agree as a community to insert the "trinity" text string in the package name. Whether as a prefix or suffix to the package base name probably is not important.

2. Whether the "R" prefix is used in the version number probably is not important. Let distro packaging rules prevail.

3. I believe the GIT short version is the best way to identify the snapshot version. Whether text strings such as "pre" are used probably is not important.

Recently I updated my package names to include the "trinity" string to avoid potential package name conflicts with KDE4. Currently I have the "trinity" string at the beginning of all package names. I could modify that to insert the "trinity" string after the base package name.

Because of the different rules for distro package naming, I suspect that where the "trinity" string is included in the package name is not as important as much that we all include the string.

I prefer the string "trinity" rather than "tde" because for many users who use package managers to search for packages, "trinity" is more descriptive than "tde."

Regarding development packages I have been pulling the GIT short version and using that number as part of the package names:

GIT_VERSION="`git shortlog . | grep -E '^[ ]+\w+' | wc -l`"

I build package sets for different Slackware releases. I use the Slackware release number and either "32" or "64" to note CPU architecture. I haven't been using other strings such as "pre," but I see no reason why others can't do that if they want. I include R14.0.0 in the package name although some people might argue I should be using "3.5.13." But the next release is forking version numbers and we have no easy way to show that the development packages are or something similar as with other projects. Thus I stick with R14.0.0 for now.

Whether all of us agree to use "R" in the version number probably is not important. If distro packaging rules require not using then do that and if there are no such rules with other distros then let the packager decide. I prefer using the "R" prefix because the current Slackware release is 14.0 and the "R" prefix helps distinguish the two numbers. :)

Just my initial thoughts on the topic. :)

This topic is important. If we agree now on a very basic naming scheme then we all have plenty of time to adjust our build scripts before we begin to approach any soft freeze. Better now to do that work than scramble like Keystone Kops when we approach the release date. :)