Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Alexis Ballier <aballier@g.o>
Subject: Re: Change policy about live ebuilds
Date: Thu, 25 Nov 2010 12:07:45 -0300
On Thursday 25 November 2010 11:22:39 Paweł Hajdan, Jr. wrote:
> On 11/25/10 2:59 PM, Alexis Ballier wrote:
> > I fail to understand why you claim that live ebuilds are a QA nightmare,
> > you may want to have a look at how I play with, eg, ffmpeg or vlc and
> > their live ebuilds: they make version bumps much easier and far less
> > error prone.
> 
> I'm just curious. Could you explain more how the live ebuilds make
> version bumps easier and less error prone?

By following closely upstream development you are able to adapt the live 
ebuild to the current status, eg, for new deps. Usually with vlc, when a new 
major version comes out, there are a couple of new features and a couple of 
outdated features removed, doing all these changes at once is more error prone 
than doing it once you notice the change for each of them in the live ebuild.

As for version bumps, the live ebuild is simply copied to an ebuild with a 
name matching the version that has just been released.

> My experience with chromium-9999 ebuild is different. Indeed users do
> test it and report very useful "early warning" bugs, but when I actually
> do a version bump I also have to modify the live ebuild, and that
> modification is usually untested.

What kind of modification do you need to do? The only cases I had to change 
anything is when the live ebuild was out of sync.

> Furthermore, when one of local Gentoo
> patches lands upstream, the live ebuild has to be modified again.

In case of a responsive upstream, like vlc or ffmpeg here, you can apply the 
policy of "backports only" for patches and have absolutely zero patches for 
the live version.  [This is not entirely true for vlc because we have some 
patches that cannot be merged that easily upstream and some of them indeed 
break from time to time]
The patch is sent upstream, modified until accepted, and backported in the 
_previous_ versions if there is a need for it. The live ebuild doesn't change, 
the patch is already here, the next release will again match the live ebuild.

> If there are some tips/techniques that work for you and make live
> ebuilds more helpful, I'd like to learn a bit more.

I usually maintain mainly the live version: any change that is not purely a 
bugfix goes to the live version, period.

Not sure if that's the kind of tips/techniques you were expecting, feel free 
to ask more questions.

A.


Replies:
Re: Change policy about live ebuilds
-- Paweł Hajdan, Jr.
Re: Change policy about live ebuilds
-- Maciej Mrozowski
References:
Change policy about live ebuilds
-- Markos Chandras
Re: Change policy about live ebuilds
-- Alexis Ballier
Re: Change policy about live ebuilds
-- Paweł Hajdan, Jr.
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Change policy about live ebuilds
Next by thread:
Re: Change policy about live ebuilds
Previous by date:
Re: Change policy about live ebuilds
Next by date:
Re: Change policy about live ebuilds


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.