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

[Duncan]

Maciej Mrozowski posted on Thu, 25 Nov 2010 18:38:59 +0100 as excerpted:

> On Thursday 25 of November 2010 16:07:45 Alexis Ballier wrote:
>> On Thursday 25 November 2010 11:22:39 Paweł Hajdan, Jr. wrote:
>> >
>> > 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. [D]oing 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).

I had just thought about posting the same thing, from a (kde and x11 
overlays user but not normally live ebuild) user perspective.

Both those overlays are git-based, and in both cases, I have a script that 
does a "git --whatchanged --reverse ORIG_HEAD..", that I run after every 
update.  Thus, I follow the overlay git commits quite closely, and see the 
above in action, even while not actually using the live versions myself.  
(I did use live for radeon drivers and etc for a bit, when my new card 
didn't have a released version, even beta or snapshot, with functional 
OpenGL support, but until 4.5, even so-called stable kde4 was hardly what 
one would call release status upstream, and I've hesitated to do live 
there simply because what upstream called stable was better qualified as 
alpha/beta, broken enough as it was.)

While both of these are overlays not in-tree live ebuilds, I can hardly 
imagine the trouble kde would have trying to do only released version 
bumps, given the size of the project and the speed at which upstream is 
changing.  xorg isn't quite as bad, but it's transparently obvious it 
helps there, as well.

Also, the experience certainly does have me eager for the main tree git 
switch-over, as the changelogs are richer and far more useful when I do 
run into problems, or better yet, avoid them, because I saw the change in 
the git --whatchanged log (the same biggest reason I read this list, BTW, 
a heads-up on changes coming down the pike, it's what a responsible 
sysadmin /does/).

Basically, the live ebuild is for package maintainers what the rolling 
update system is for sysadmin/users.  It switches the process from what is 
effectively a periodic rather opaque big code-dump update, to "rolling 
updates", allowing the admin/maintainer to manage only a handful of 
updates at a time, working thru the problems as they appear, when they can 
still be traced back to individual changes when the inevitable issues do 
occur, and reacted to accordingly.  If the whole rolling update concept 
makes sense, and it does or Gentoo wouldn't be using it, at least on 
complex packages/suites with enough change going on to warrant close 
maintainer attention, live ebuilds closely following upstream's many 
between-release changes make sense as well.

And getting those live ebuilds out there for brave users willing to break 
their systems to beat on and report bugs on as necessary, certainly 
doesn't hurt! =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman