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