[gentoo-dev] CVS versions and portage management

[gentoo-dev] CVS versions and portage management

[marco mascherpa (aka mush)]

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

-- 
Icy-Q 41982464
discussioni.org IRCoperator

"Have you seen my girl?
She's the one with the curly hair.
She was sitting just right over there, 
now she's nowhere to be found."
Flying Blind

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

[Spider]

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

theres some interesting thoughts here, and theres been a bit of work
done on it, check out the cvs eclass made by Dan Armak. 

I'm not going to go in further on the cvs issues since its not a big
concern of mine at the moment, I'm struggling enough with released
applicatinos to do unreleased ones :)

//Spider




--
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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