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
