On Thursday 25 of November 2010 16:07:45 Alexis Ballier wrote: > 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.
It may be worth mentioning it's exactly how all kde-base ebuilds are prepared. We just svn up in distfiles occasionally, look for changes in buildsystem and adjust live (stable branch or trunk) ebuilds accordingly (that being said 4.x.9999 live ebuilds usually reflect the best KDE version available). Many Gentoo KDE devs use 4.x.9999 on daily basis (and actually they should) and thus are able to evaluate patches and take them directly from disfiles via svn diff -r prev:patchrev to tree if needed. Ebuilds you see in tree are just generated versions of live ones (blind copy with replaced keywords, we use bump tool for it however). -- regards MM
signature.asc
Description: This is a digitally signed message part.
