Re: [gentoo-dev] CVS versions and portage management

[Dan Armak]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I'm Dan Armak, the kde-base maintainer. This is a topic I could (and have) 
write a lot about, I'll try to give you a summary:

Until the kde 3.0 release (March), I maintained for several months a set of 
KDE cvs ebuilds outside portage (since cvs ebuilds haven't been sanctioned as 
yet). You can find the last release on 
http://www.gentoo.org/~danarmak/kde3-pre.html. 

I used eclasses to implement automatic cvs/cvsup checkout/update/etc. and 
seamless compilation and installation. If you don't know about eclasses see 
http://www.gentoo.org/doc/eclass-howto.html. You can see kde-cvs.eclass, 
kde-cvsup.eclass and kde-source.eclas in the archive on my site referenced 
above, they complement the kde-* eclasses present in portage.

However I didn't solve the versioning issue, I named the ebuilds version 3.0 
since that was the version towards which the kde cvs was working. But 
obviously this wouldn't be any good on a larger scale.

Some time ago I wrote a proposition on introducing cvs ebuilds into portage, 
with a versioning scheme. The discussion was on the developer-only 
gentoo-core list, so you can't browse the archives. I quote:
- ---
"Bevin and I discussed CVS ebuilds in #gentoodev and came up with the 
following 
improved proposal:

An ebuild can have a version, a cvs name element, or both. The order of 
version precedence is as follows:

foo-cvs > foo-2.0-cvs > foo-2.0 > foo-1.0-cvs > foo-1.0

A cvs ebuild without a version gets its source from cvs HEAD, so it's always 
newest. When it is emerged, however, it is automatically given (i.e. by 
emerge) the version number of the latest non-cvs ebuild in existence. If only 
the cvs ebuild exists, it gets version 0.

That way, when a new non-cvs ebuild is added with a greater version, it serves 
as an update. The DATE variable is no longer needed.

A cvs ebuild with a version gets code from a specific tag or branch on cvs. 
Usually the branch of a version only gets bugfixes, not new features, so it's 
extra-stable.

Because a cvs ebuild is always newer than a itself merged a few minutes ago, 
we won't let them into the world update. Instead we can add a new emere 
- --update cvs that will update all cvs ebuilds, or emerge --cvs which will 
allow cvs ebuilds to be merged (i.e. when merging new packages)."

- ---


And some 10 days ago Daniel Robbins said:
"Dan Armak and others have already worked out a plan for adding this to
Portage; you should be able to find it in the gentoo-core archives.  It
will be added eventually, but I'm going to be focusing on more
fundamental things for a while (robustness, error handling, streamlining
the code.)"

That's all that known atm.

On Tuesday 28 May 2002 18:33, marco mascherpa (aka mush) wrote:
> hi,
> it's the first time i write to this ML, altough i've been subscribed for a
> while. i'm an italian guy, i'm studying information engineering in milan
> and i'm a happy linux user. :) at the moment i'm enjoying a slackware, but
> some months ago i found this gentoo and i think it's really awesome! it
> merges the goods of both linux and BSD which i appreciate too! so i thought
> this is a great project and i'm planning to join you developers as soon as
> my skills will permit it and i will know enough of gentoo to avoid those
> RTFM questions. :)
>
> now, let's go to the meat: last night i happened to install the CVS version
> of gaim (the open source AIM clone) and suddenly i wondered how could
> gentoo portage system manage the install/upgrade process of a CVS snapshot
> of an application. it could seem a weird situation, why would we need to
> install the CVS snapshot when we have the official releases? as you know
> better than me sometimes some features we need are available only in the
> CVS version: for example licq CVS version is perfectly compatible with the
> latest ICQ protocol, but the official release isn't. but there are much
> more interesting cases than this one, i guess :)
>
> AFAIK the portege system cannot manage the CVS version of an app and
> decide, for instance whether the version we are considering is older or
> newer than the installed one: i can't upgrade a program with his CVS
> version.
>
> i found two possible solutions to this problem:
> - we could make a separate ebuild for every pregram: let's say we have the
> ebuild of program foo, version 1.2.3: we have a foo-1.2.3-r1.ebuild for the
> official release and a fooCVS-20020528-r1.ebuild for the CVS version. this
> would lead to some coexistence inssues but it would be very easy to do and
> wouldn't require any changes in the portage system.
> - otherwise we could include in the ebuild a DATE variable wich will
> contain the release date for official releases and the date of the CVS
> snapshot for CVS versions. obviously this would mean some changes in the
> way upgrade and dependencies are managed, but i think it wouldn't be too
> hard to implement.
>
> i hope my thoughts will be useful in some way and again i congratulate you
> for the optimum job you have made so far.
> best regards
> 	marco

- -- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE889ZGUI2RQ41fiVERAj8HAJ9mwHzHvh/FWa2vMCgGbjPoSy4LTgCfS5vz
7yOvC0nt13IU1JCZVn/O2Ec=
=6upx
-----END PGP SIGNATURE-----