On Wed, Aug 24, 2005 at 01:14:36PM +0200, Johannes Winkelmann wrote:
Do we name the port 'port'-svn or just 'port' with the version 'svn' ? Depends on what "we" means.
No comment :) You all know where I stand I hope.
Speaking for CLC, there's no official guideline though, since we are following CRUX' motto, which is "latest stable".
*nods*
Whether you want to call it "name=blackbox-cvs, version=2005-08-24" or "name=blackbox, version=cvs-2005-08-24" is up to you, but I'd go for the later, since this will allow users to update to the next regular version without using pkgadd -f to take over the files (or remove the cvs port before, in which case they'd have to manually back up the configuration files). That said, this of course means that mplayer-1.0pre7-1 and mplayer-20050806 would conflict (currently, they don't since the later is called mplayer-cvs). Users could still get them by subscribing directly to your httpup. The question really is "does it make sense to have both mplayer and mplayer-cvs available in the ports tree?". If yes, then using a 'cvs' postfix might be better. There's a similar issue with '-dev' and '-devel' ports by the way.
I think it's important to add that for contrib-new (and any other port you publish for use by others), I'd strongly suggest not to have any ports which don't have a predictable build result. Instead, create a tarball from a version which is known to work, and upload it to your webspace. (Your mplayer-cvs and ffmpeg-cvs ports are good examples for this; other '-cvs' port check out the current CVS tree from within build(), which sort of conflicts with predictable build results).
I guess since the mpd development team don't have a tarball of the current tree of their software, I'd have to tar it up myself and put it in my own webspace :) That being said, I think I'll just wait till they release the new version (and maybe Han can update his port). Although that being said, I want to use the "shout" feature of mpd (Han if you're reading this when 0.12.0 comes out). I do agree with you btw, that ports should have a predictable build and be based on tarballs that do work. As far as naming is concerned with such ports I'd go for: name=foo version=svn-20050824 or name=foo version=svn-23 (where 23 is some revision number) cheers James -- -- -"Problems are Solved by Method" -