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.
signature.asc
Description: OpenPGP digital signature
