| 1 |
On Tuesday 01 July 2003 22:35, Todd Berman wrote: |
| 2 |
> On Tue, 2003-07-01 at 15:13, Paul de Vrieze wrote: |
| 3 |
> > On Tuesday 01 July 2003 21:08, James H. Cloos Jr. wrote: |
| 4 |
> > > Has anyone done any work towards an svn.eclass ala cvs.eclass? |
| 5 |
> > > |
| 6 |
> > > Or a bk.eclass for that matter? |
| 7 |
> > > |
| 8 |
> > > I don't see anything on 'zilla. |
| 9 |
> |
| 10 |
> Amir had one, i know this, but before we rush to put it into the tree, |
| 11 |
> is there really a need for it? |
| 12 |
|
| 13 |
Well, what important or interesting apps use subversion or bitkeeper for which |
| 14 |
we might want live ebuilds? Hm, the linux kernel :-) Anything else? (This |
| 15 |
question is addressed to the orig poster) |
| 16 |
|
| 17 |
I tried to write a cvsup.eclass once, but never brought it up to the same |
| 18 |
level as cvs.eclass because I didn't need it. Still, writing such an eclass |
| 19 |
(or svn/bk/rsync/whatever), with the experience gained from the many |
| 20 |
cvs.eclass debacles, shouldn't be very difficult or take very long, the |
| 21 |
bigger question is whether we want it. |
| 22 |
|
| 23 |
> |
| 24 |
> I was pretty sure live cvs/svn/bk ebuilds were something we wanted to |
| 25 |
> move *away* from, not to. |
| 26 |
|
| 27 |
Well, not as such, I think. They are legitimately useful in certain |
| 28 |
situations. |
| 29 |
|
| 30 |
In the example of the kde live cvs ebuilds, they (and the users constantly |
| 31 |
testing them) have been an excellent tool for me to test various improvements |
| 32 |
to the kde ebuilds, and more importantly, to have ready, well tested code for |
| 33 |
new KDE releases. The ebuilds for eg kde 3.0 and 3.1 differ significantly; |
| 34 |
instead of having to spend a lot of time and effort during the week kde |
| 35 |
packagers are given to look at the new release source tarballs searching for |
| 36 |
all those differences, I can now use ebuilds that are known to work for the |
| 37 |
cvs of a week ago. |
| 38 |
|
| 39 |
The users of course benefit as well - not just those who like running the |
| 40 |
bleeding edge for its own sake, but kde developers. Several have told me the |
| 41 |
availability of semiofficial 'live cvs' packages has been a big benefit of |
| 42 |
gentoo over other distros. |
| 43 |
|
| 44 |
Another case where such ebuilds are useful is when an app has a rapidly |
| 45 |
evolving cvs tree which is not much less stable than its releases (like wine |
| 46 |
I think). Users using cvs as often as not get a stabler version than the |
| 47 |
latest release, with important fixes. A developer could of course create |
| 48 |
frequent cvs snapshot ebuilds or include specific fixes in ebuilds based on |
| 49 |
the latest release, but this would require a very large amount of effort. |
| 50 |
|
| 51 |
All this said, I refrain from putting my own kde cvs ebuilds in the portage |
| 52 |
tree until portage has better support for live cvs ebuilds (blocking |
| 53 |
keywords, better dep handling --> recognition of 'cvs' as a version, maybe |
| 54 |
even understanding of branches). |
| 55 |
|
| 56 |
-- |
| 57 |
Dan Armak |
| 58 |
Gentoo Linux developer (KDE) |
| 59 |
Matan, Israel |
| 60 |
Public GPG key: http://cvs.gentoo.org/~danarmak/danarmak-gpg-public.key |
| 61 |
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 |
Archives