[clc-devel] CVS/SVN Versions of ports (policy?)
HI GUys, What is our policy on providing cvs/svn versions of ports ? Do we name the port 'port'-svn or just 'port' with the version 'svn' ? cheers James -- -- -"Problems are Solved by Method" -
Hi, On Wed, Aug 24, 2005 at 20:18:49 +1000, James Mills wrote:
HI GUys,
What is our policy on providing cvs/svn versions of ports ?
Do we name the port 'port'-svn or just 'port' with the version 'svn' ? Depends on what "we" means.
Speaking for CLC, there's no official guideline though, since we are following CRUX' motto, which is "latest stable". 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). HTH, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
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" -
On Wed, Aug 24, 2005 at 01:14:36PM +0200, Johannes Winkelmann wrote:
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.
Well, I think also that we should not have a separate port for the CVS version. Personally I would say that it's better to have two ports which are different in the version and not in the name. For example if we want one CVS and one stable version of mplayer I would say that the latest stable version of it should belong to the contrib repository and the cvs version (both are named equally) should belong to a private httpup repository. I think that a CVS version is definite that what can be considered as an exotic port and therefore it doesn't belong to the contrib repository. Now everyone can switch easily between the stable and the CVS version of mplayer. And if the port isn't popular enough to get into the contrib repository it doesn't make any sens to create ports with different versions of it. Regards Viper
On Wed, Aug 24, 2005 at 05:12:33PM +0200, Simon Glo?ner wrote:
Well, I think also that we should not have a separate port for the CVS version. Personally I would say that it's better to have two ports which are different in the version and not in the name. For example if we want one CVS and one stable version of mplayer I would say that the latest stable version of it should belong to the contrib repository and the cvs version (both are named equally) should belong to a private httpup repository. I think that a CVS version is definite that what can be considered as an exotic port and therefore it doesn't belong to the contrib repository. Now everyone can switch easily between the stable and the CVS version of mplayer. And if the port isn't popular enough to get into the contrib repository it doesn't make any sens to create ports with different versions of it.
*nods* I agree. I willi in that case not sync my mpd-svn port :) And when the mpd team release 0.12.0 (with 'shout' support) I'll remove it. cheers James -- -- -"Problems are Solved by Method" -
--- Simon Gloßner <viper@hometux.de> wrote:
Well, I think also that we should not have a separate port for the CVS version. Personally I would say that it's better to have two ports which are different in the version and not in the name. For example if we want one CVS and one stable version of mplayer I would say that the latest stable version of it should belong to the contrib repository and the cvs version (both are named equally) should belong to a private httpup repository. I think that a CVS version is definite that what can be considered as an exotic port and therefore it doesn't belong to the contrib repository. Now everyone can switch easily between the stable and the CVS version of mplayer. And if the port isn't popular enough to get into the contrib repository it doesn't make any sens to create ports with different versions of it.
Along these lines, perhaps we should consider creating a[nother] merged ports repo (ala prtsync) called contrib-testing (or something) for these types of ports. Maintainers can tag all of their cvs/bleeding edge ports for this new place, thus making them readily available to masses and not cluttering/breaking contrib. Just an idea. Jay Dolan Software Engineer, Systems Analyst Windmill Cycles, Inc. 508.999.4000 __________________________________ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html
On Wed, Aug 24, 2005 at 08:29:57AM -0700, Jay Dolan wrote:
Along these lines, perhaps we should consider creating a[nother] merged ports repo (ala prtsync) called contrib-testing (or something) for these types of ports. Maintainers can tag all of their cvs/bleeding edge ports for this new place, thus making them readily available to masses and not cluttering/breaking contrib.
The question is: Do we want to provide "latest bleeding edge" software that may have defects that haven't had time to be fixed yet ? I think this would be heading down the path of Debian (which I always thought wasn't really a great idea). I guess I'm thinking of non-technical users here, whom may want to try "latest bleeding edge" stuff only to find it breaks. cheers James -- -- -"Problems are Solved by Method" -
On Thu, Aug 25, 2005 at 01:35:28AM +1000, James Mills wrote:
The question is:
Do we want to provide "latest bleeding edge" software that may have defects that haven't had time to be fixed yet ?
I think this would be heading down the path of Debian (which I always thought wasn't really a great idea). I guess I'm thinking of non-technical users here, whom may want to try "latest bleeding edge" stuff only to find it breaks.
Well, I think also that we should _not_ try to provide CVS or beta versions for the majority of our ports. Personally I believe it's better to have one good port of the latest stable version than providing many different versions with bugs or other problems. I think that the majority (containing me) doesn't want to use bleeding edge software with some serious bugs. Regards Viper
--- Simon Gloßner <viper@hometux.de> wrote:
Well, I think also that we should _not_ try to provide CVS or beta versions for the majority of our ports. Personally I believe it's better to have one good port of the latest stable version than providing many different versions with bugs or other problems. I think that the majority (containing me) doesn't want to use bleeding edge software with some serious bugs.
I only brough it up because _obviously_ it is an issue for some ports. Personally, I run -rc kernel pre-patches, X.org cvs, and other pre-release software. These things don't scare me very much. I wasn't suggesting that a new repository for this sort of stuff belongs in mainline Crux, either. The ports driver file could be user-installed. Jay Dolan Software Engineer, Systems Analyst Windmill Cycles, Inc. 508.999.4000 ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
On Wed, Aug 24, 2005 at 08:58:57AM -0700, Jay Dolan wrote:
I only brough it up because _obviously_ it is an issue for some ports.
*nods*
Personally, I run -rc kernel pre-patches, X.org cvs, and other pre-release software. These things don't scare me very much. I wasn't suggesting that a new repository for this sort of stuff belongs in mainline Crux, either. The ports driver file could be user-installed.
Well if some of us didn't, defects would never be found and fixed :) Now that you've made it more clear, I do agree. As long as this new repo doesn't become part of mainline crux, fine. It'll just become part of a repo that maintainers/developers (technical users of crux) can use if they wish. cheers James -- -- -"Problems are Solved by Method" -
On Wed, Aug 24, 2005 at 08:58:57AM -0700, Jay Dolan wrote:
I only brough it up because _obviously_ it is an issue for some ports.
Personally, I run -rc kernel pre-patches, X.org cvs, and other pre-release software. These things don't scare me very much. I wasn't suggesting that a new repository for this sort of stuff belongs in mainline Crux, either. The ports driver file could be user-installed.
Yes, we have to consider if we want to concentrate all CVS versions or if it's ok if they are scattered into many private repositories. Personally, I think it isn't necessery to create an extra repository for it. Regards Viper
On Wed, 2005-08-24 at 08:29 -0700, Jay Dolan wrote:
Along these lines, perhaps we should consider creating a[nother] merged ports repo (ala prtsync) called contrib-testing (or something) for these types of ports. Maintainers can tag all of their cvs/bleeding edge ports for this new place, thus making them readily available to masses and not cluttering/breaking contrib.
I'd prefer this sort of bleeding edge stuff to stay in personal httpup repos, myself, they're already a great mechanism for it. That said, no one's forced to use whatever repo that ends up being, so go to. :) Matt (jaeger@freenode/#crux)
On Wed, 2005-08-24 at 13:14 +0200, Johannes Winkelmann wrote:
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).
I agree with this, prefer port names to be the same as they reflect the name of the product itself. Matt (jaeger@freenode/#crux)
participants (5)
-
James Mills -
Jay Dolan -
Johannes Winkelmann -
Matt Housh -
Simon Gloßner