[Slackbuilds-users] new pdksh package and slackbuild

Heinz Wiesinger pprkut at slackbuilds.org
Fri Apr 2 06:01:28 UTC 2010

On Friday 02 April 2010 02:46:54 Niels Horn wrote:
> On Thu, Apr 1, 2010 at 3:44 PM, LEVAI Daniel <leva at ecentrum.hu> wrote:
> > On Tue, Mar 30, 2010 at 09:54:34AM -0500, Robby Workman wrote:
> > [...]
> > 
> >> > had been fixed. My question is that is there a demand for this
> >> > improved pdksh among the existing pdksh users, and is it acceptable
> >> > that I discontinue the current pdksh slackbuild (based on the
> >> > original pdksh), and start to work on the OBSD's version of pdksh?
> >> 
> >> I'd suggest to replace our current pdksh with the OpenBSD version.
> > 
> > What do you suggest to use for version numbering/naming? Is there a
> > working versioning mechanism for other cvs based slackbuilds?
> > 
> > 
> > Daniel
> Daniel,
> I have had some SlackBuilds in the past based on CVS or SVN snapshots
> and always used "cvs_yyyymmdd" or "svn_yyyymmdd" as the version
> number, so that it's clear from when the snapshot is.
> To guarantee that your SlackBuild works with the snapshot, you will
> have to have it hosted somewhere, since the cvs/svn repository might
> change daily.
> I hosted it on my own server as a tarball.

IMHO using date as a version string for vcs snapshots of a version is not 
really that useful. Svn repositories change a lot, even during the time of a 
day, so how should I know exactly from what time of the day it is? Adding the 
time to the version string doesn't really help there as it's timezone 
dependent, and so on....
Unfortunately I haven't yet came across anything more useful than date for cvs 
snapshots. For svn I use the revision numbers as "r$REVISION", same for bzr. 
For git I use the short hash appended with the date (since by only using the 
hash it's very difficult to figure out which version is actually newer).
I havn't had the pleasure yet of having to figure out a version string for 
other vcs systems like mercurial, darcs, ....

In the end, the versioning in that case is up to the maintainer (as long as 
it's reasonable). What *is* however important, is that you base the script on 
one specific snapshot that's hosted somewhere (either by your own or by someone 
else). We do not allow direct checkouts within SlackBuilds, like Matteo 
mentioned in his post (you can add it as a comment though, somewhere in the 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20100402/8e445a79/attachment.sig>

More information about the SlackBuilds-users mailing list