Re: [gentoo-dev] Change policy about live ebuilds

[Alexis Ballier]

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.