[gentoo-dev] how CVS ebuilds are managed

[gentoo-dev] how CVS ebuilds are managed

[Robert Thomas]

Instead of having a separate package for a cvs version of a package, why 
not consider the cvs version to be the latest version of a package, but 
always marked unstable? Since the cvs version of a package usually 
overwrites the existing version, the old version should be automagically 
unmerged. For example, in the case of gaim and gaim-cvs, if the cvs 
version of gaim is installed, the stable version should be unmerged as 
if it was an old version of the package. Perhaps there is another way to 
manage this.
In the case of binary packages (like openoffice-bin), they should also 
be considered to be the same package, but still kept separate in some way.
Perhaps another USE flag?
# USE="bin" emerge openoffice

Or maybe cvs could be a new keyword:
# ACCEPT_KEYWORDS="cvs" emerge gaim

Ok, I really am talking out of the wrong orifice here, and I know that 
these ideas are probably a misuse of USE flags and KEYWORDS. I would 
just like to know if something like this could work (not necessarily the 
way I've described it, perhaps a different extention to the version 
calculating routine altogether), or if there is a reason these packages 
are managed the way they are (by "these" I mean all packages ending in 
"-bin" or "-cvs").

-- 
Cicero (Robert Thomas)
CS Major @ GA Tech
Email: rwt@cc.gatech.edu


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] how CVS ebuilds are managed

[Mark Gordon]

On Tue, 29 Apr 2003 14:21:40 -0400
Robert Thomas <rwt@cc.gatech.edu> wrote:

> Instead of having a separate package for a cvs version of a package,
> why not consider the cvs version to be the latest version of a
> package, but always marked unstable?

They can't be done as ~arch as if I understand it this is testing and
things should be likely to work but CVS builds stand a reasonable chance
of failing due to upstream changes.

> Since the cvs version of a
> package usually overwrites the existing version, the old version
> should be automagically unmerged. For example, in the case of gaim and
> gaim-cvs, if the cvs version of gaim is installed, the stable version
> should be unmerged as if it was an old version of the package. Perhaps
> there is another way to manage this.
> In the case of binary packages (like openoffice-bin), they should also
> be considered to be the same package, but still kept separate in some
> way. Perhaps another USE flag?
> # USE="bin" emerge openoffice
> 
> Or maybe cvs could be a new keyword:
> # ACCEPT_KEYWORDS="cvs" emerge gaim
> 
> Ok, I really am talking out of the wrong orifice here, and I know that
> these ideas are probably a misuse of USE flags and KEYWORDS. I would 
> just like to know if something like this could work (not necessarily
> the way I've described it, perhaps a different extention to the
> version calculating routine altogether), or if there is a reason these
> packages are managed the way they are (by "these" I mean all packages
> ending in "-bin" or "-cvs").

Well, the ebuild has to be significantly different for a binary version
to a source version, so trying to mix them would probably be a
maintenance problem.

Also the binary version might be ready to go stable
before the source version, since it effectively only has to deal with
*one* set of flags.
-- 
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Currently looking for a new job commutable from Slough, Berks, U.K.
Although my email address says spamtrap, it is real and I read it.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] how CVS ebuilds are managed

[Abhishek Amit]

On 14:21 Tue 29 Apr     , Robert Thomas wrote:
> Instead of having a separate package for a cvs version of a package, why 
> not consider the cvs version to be the latest version of a package, but 
> always marked unstable? Since the cvs version of a package usually 
> overwrites the existing version, the old version should be automagically 
> unmerged. For example, in the case of gaim and gaim-cvs, if the cvs 
> version of gaim is installed, the stable version should be unmerged as 
> if it was an old version of the package. Perhaps there is another way to 
> manage this.
> In the case of binary packages (like openoffice-bin), they should also 
> be considered to be the same package, but still kept separate in some way.
> Perhaps another USE flag?
> # USE="bin" emerge openoffice
> 
> Or maybe cvs could be a new keyword:
> # ACCEPT_KEYWORDS="cvs" emerge gaim
> 
> Ok, I really am talking out of the wrong orifice here, and I know that 
> these ideas are probably a misuse of USE flags and KEYWORDS. I would 
> just like to know if something like this could work (not necessarily the 
> way I've described it, perhaps a different extention to the version 
> calculating routine altogether), or if there is a reason these packages 
> are managed the way they are (by "these" I mean all packages ending in 
> "-bin" or "-cvs").
> 
> -- 
> Cicero (Robert Thomas)
> CS Major @ GA Tech
> Email: rwt@cc.gatech.edu
> 
> 
> --
> gentoo-dev@gentoo.org mailing list
> 
I don't even think this is really important, as cvs ebuilds are meant to
be sued sparingly(only when the release version is really old, as gaim
was and I'm sure there are some other critereia that can be used).
gaim-cvs is depreacted now. Perhaps it is just me, but I really don't
see the point in adding mroe features to prtage for three or four
packages.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] how CVS ebuilds are managed

[Mark Bainter]

Abhishek Amit [abhishekamit2000@yahoo.com] wrote:
> I don't even think this is really important, as cvs ebuilds are meant to
> be sued sparingly(only when the release version is really old, as gaim
> was and I'm sure there are some other critereia that can be used).
> gaim-cvs is depreacted now. Perhaps it is just me, but I really don't
> see the point in adding mroe features to prtage for three or four
> packages.

I would disagree with this.  I have quite a few ebuilds that are in
my local portage tree purely so I can run the cvs version of a few
appliations and still manage it with portage.  It would definately
be nice if there was a clean way to handle it within the portage
system itself.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] how CVS ebuilds are managed

[Martin Schlemmer]

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

On Thu, 2003-05-08 at 18:35, Mark Bainter wrote:

> I would disagree with this.  I have quite a few ebuilds that are in
> my local portage tree purely so I can run the cvs version of a few
> appliations and still manage it with portage.  It would definately
> be nice if there was a clean way to handle it within the portage
> system itself.
> 

We do not really want to support it officially, as there are no way
to do proper QA on it.  Rather then use a static cvs snapshot, as
that you can apply patches to, etc.


-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] how CVS ebuilds are managed

[Mark Bainter]

Martin Schlemmer [azarah@gentoo.org] wrote:
> On Thu, 2003-05-08 at 18:35, Mark Bainter wrote:
> 
> > I would disagree with this.  I have quite a few ebuilds that are in
> > my local portage tree purely so I can run the cvs version of a few
> > appliations and still manage it with portage.  It would definately
> > be nice if there was a clean way to handle it within the portage
> > system itself.
> > 
> 
> We do not really want to support it officially, as there are no way
> to do proper QA on it.  Rather then use a static cvs snapshot, as
> that you can apply patches to, etc.

Hrm.  How do you mean?  Do you mean you don't want to make it easier
to do because it might appear you support those types of packages,
or that you don't want to put those sorts of ebuilds in the tree 
other than in one-off cases?

If the latter, I don't think that necessarily excludes the possibility
of providing some sort of support for that type of package within 
portage itself as a convenience for those of us writing the builds
locally right?

Though obviously, since it's not going to be used by gentoo at large
I would expect that one of us who actually has to deal with it would
spend the time writing it, as better uses of official gentoo developer
time exist. 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] how CVS ebuilds are managed

[Matthew Kennedy]

Robert Thomas <rwt@cc.gatech.edu> writes:

> Instead of having a separate package for a cvs version of a package,
> why not consider the cvs version to be the latest version of a
> package, but always marked unstable? Since the cvs version of a
> package usually overwrites the existing version, the old version
> should be automagically unmerged. For example, in the case of gaim and
> gaim-cvs, if the cvs version of gaim is installed, the stable version
> should be unmerged as if it was an old version of the package. Perhaps
> there is another way to manage this.
> In the case of binary packages (like openoffice-bin), they should also
> be considered to be the same package, but still kept separate in some
> way.
> Perhaps another USE flag?
> # USE="bin" emerge openoffice
> 
> Or maybe cvs could be a new keyword:
> # ACCEPT_KEYWORDS="cvs" emerge gaim
> 
> Ok, I really am talking out of the wrong orifice here, and I know that
> these ideas are probably a misuse of USE flags and KEYWORDS. I would
> just like to know if something like this could work (not necessarily
> the way I've described it, perhaps a different extention to the
> version calculating routine altogether), or if there is a reason these
> packages are managed the way they are (by "these" I mean all packages
> ending in "-bin" or "-cvs").


>From a developer's standpoint, having one ebuild for both release and
CVS versions would usually clutter the ebuild substantially.  At least
I *know* this would be the case with the emacs and emacs-cvs ebuilds.

Secondly, there's no reason why a CVS ebuild should override the
release version you might already have installed.  There just happens
to be no policy (afaik) on this particular matter.  Technically, I
think its the way to go (ie. simultaneous version).  

Matt

-- 
Matthew Kennedy
Gentoo Linux Developer


--
gentoo-dev@gentoo.org mailing list