This is a feature request: I've been writing cvs ebuilds (inheriting from the cvs eclass which is pretty dang cool) for the last couple of days, and its brought something to my attention. CVS ebuilds are quite unsupported in the current version of portage. I think that -cvs should be a version tag (with a ~x86 keyword or masked or something) so that people can emerge the current cvs version of a package. As of right now, there is gaim and gaim-cvs two different packages, becuase portage doesn't support -cvs as a version tag. If in our net-im/gaim directory we had for instance gaim-0.59.4.ebuild and gaim-cvs.ebuild, people could unmask the cvs and emerge it. In keeping with this, portage could treat a -cvs version as a sort of exception to the typical rules, every time an emerge -u world/*-cvs/<something>-cvs was done, it could sync trees, and if there were changes it could recompile and install again. (or they could be installed oneshot by default, and you specify to upgrade them, or something). Becuase CVS versions are faily unstable, if one failed on compile, it could revert to the version currently in use (after informing the user it failed on this date). Maybe it could ask them if they want to install the last stable version. I dunno, these are just ideas i've had that would make Gentoo better support CVS ebuilds. I'd personally love to see some of these features, i think they would add a lot to a distro that prides itself on building from source ;-) seth
hi! what about support for versioning with cvs? so that the user can [in some way] say: hey i want -rXX instead of -rHEAD .... just my 2c greetings, LordVan
hi! just had kinda idea: what about a version-scheme like this vor cvs: <package-name>-cvs-<Version or HEAD>.ebuild that way we could say we get e.g. mozilla releases with cvs cuz the packages are quite big .. greetings, LordVan
close this if you want, i'm not sure what the feelings are toward this
another thing to take into consideration would be support for nightly tarball ebuilds ... this would have to make some assumptions on the md5sum ... like that it always worked ;)
*** Bug 14433 has been marked as a duplicate of this bug. ***
*** Bug 16028 has been marked as a duplicate of this bug. ***
It would be good to get this into portage, so that rather than have separate dirs for cvs (eg gaim and gaim-cvs), then they're under 1 dir. I disagree with the original poster of this bug on the 'emerge world' integration. CVS is CVS, and you should only be using it if you're a developer or testing out a future developing version. Hence there should be no need to sync trees etc just to check, you just invoke 'emerge -cvs appname' periodically when you know there's been an update or you are just interested. Thomas Raschbacher has the best point in that you have to allow it to handle different versions / branches somehow. # emerge appname --cvs VERSIONorMODULE Where would the cvs files get downloaded to since they are not a tar.gz? This is key in case people want to make minor changes (using cvs) to the files downloaded, prior to compilation. Seth: don't be so negative. :)
# emerge appname --cvs VERSIONorBRANCH While specifiing the tag is flexible, it is also mode dangerous and often illogical. ebuild file must double-check that the version/branch, specified by --cvs option, is in the list (!) of supported tags by this given ebuild. Unsupported version/branch in CVS may require different compilation procedure and that means a different ebuild revision for us. BTW, why do you want to specify module in the following command? # emerge appname --cvs MODULE I think the list (that's right - again the list!) of modules must be specified in the ebuild file and must be varied from ebuild (package) revision to ebuild revision. Speaking about location... I suggest to consider the system-wide local cvs repository sitting, let's say, in /usr/portage/cvsfiles. So, if the method of download is CVS than ebuild will checkout there. Why system-wide? same logic as for /usr/portage/distfiles - it can be used by other applications.
Typo. It was : While specifiing the tag is flexible, it is also mode dangerous and often illogical. Must be: While specifiing the tag is flexible, it is also *might be* dangerous and often illogical.
I like the idea of additional -nitgly and -cvs version tags, question is how to deal with world updates? Not updating at all or updating everytime, both are annoying :/
either (1) not updating at all or (2) allowing the user to specify a variable in make.conf that determines the # of days between updates
IMHO, if the given ebuild file is specifying an expiration (nightly, weekly etc snapshots) than next time I am doing "emerge -p world" it should include such package to the list as "available for being upgraded". And it won't be a bad idea to have "ALLOW_NIGHTLY = NO" in /etc/make.conf for users who doesn't participate in active cvs snapshot testing.
Been some months.. Will this ever happen?
boy would this be a nice feature :)
Ok, first step implemented in CVS (bug #37406).
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;)
seems to be in 2.1 of sorts
Yep, 2.1 has a -cvs version prefix, so 'foo-cvs.1.0.ebuild' is a valid ebuild name for package 'foo'. Any version with that prefix will win a comparison against any version without it. As for revision/tag support, you'll have to handle that yourself (or use the rest of $PF somehow in an eclass).
*** This bug has been marked as a duplicate of 37406 ***
