Bugzilla Bug 9202

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 ***