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

On 11/25/10 4:07 PM, Alexis Ballier wrote:
> 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.

Ah, I see. It makes sense. In the case of www-client/chromium, we have
weekly "dev channel" releases, which go through Google's QA etc, and
it's useful for me to work based on those and not the trunk for
packaging. Everything else seems to work very similarly for me.

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

I do adjustments for dev channel releases, and when I need to do them,
the live ebuild usually is out of sync, so I forward-port the fixes to
the live ebuild.

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

Right, Chromium is actually very responsive and I'm also a Chromium
committer, so upstreaming patches is usually easy.

However, my patches related to using system libraries instead of bundled
copies are often "controversial", so getting them through code review
takes some time.

Most of the time when I'm making local patches, they fix _regressions_
in the system library support, i.e. we were using a system library, but
an upstream change broke it.