walt <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Wed, 09 Jul 2008 00:22:39 +0000:
> On Mon, 07 Jul 2008 20:49:48 +0000, Duncan wrote: > >> I actually got the Gentoo-dev pan maintainer interested in my svn-live >> ebuild and mailed it to 'em yesterday. I'm not sure if it'll end up in >> the main package tree or not, however, being a live-ebuild. General >> policy is they don't go in, tho there's a few exceptions. > I'm a gentooer also but I've not heard the word 'live' used that way. > What does it imply? Take a look at pretty much any ebuild of version 9999 or a variant thereof (the amarok-1.4.9999-r2 I happen to have merged from the tree, for instance). They are "live" ebuilds, in that they pull source from the "live" VCS tree (VCS=version control system, CVS/SVN/GIT/whatever), and thus, unlike regular ebuilds or vcs-snapshot ebuilds (which pull a fixed snapshot that won't change), pull and compile from literally different sources each time they're merged (well, obviously if the upstream repository has had any commits since the last time, anyway). It follows that live-ebuilds are essentially unsupported (and therefore always hard-masked), because a duplication of the build conditions including sources simply isn't practical. However, where available (and most such ebuilds are now kept in the various overlays, not in the main tree), they /do/ provide a convenient automated and package-manager tracked way of managing what would otherwise be manually pulled, compiled and installed live-vcs sources. So, after managing pan's live-svn sources by hand for awhile, I took a look at some of the other live-svn packages in the tree, most of which use svn.eclass, and after studying the eclass a bit as well, basically merged the svn bits from some other live-svn package with the existing pan-0.1xx ebuild at the time, of course changing the various parameters used by svn.eclass as appropriate for the pan case, as opposed to whatever they were in whatever ebuild I copied them from. Now I get the benefits of both whatever's the latest in the gnome/pan svn repository and portage's package management automation, and all I have to remember to do is remerge pan occasionally, since a live-ebuild version won't change and let you know there's an update that way, as most package ebuilds do. If I'm lucky, "eva" (Gilles D. according to the gentoo dev list; I'm not French but I think that's a guy) will decide to put it in the main tree anyway, and I'll be able to eliminate my private overlay version. Or maybe he was simply interested in using it personally, the better to keep track of what's happening between versions, and therefore get a head- start on any necessary ebuild changes. That'd still be of benefit to Gentoo pan users, tho not as much to me personally. If the live ebuild does make it to the tree, it's likely I'll file bugs on it as upstream changes and they are necessary. I'm considering proxy- maintaining it as well, tho I've not talked to anyone about it yet. We'll see how it goes; whether eva trees it or mails me any questions, or others ask me about/for it after seeing it mentioned here or on the bug. Right now I'm just playing it by ear. Anyway, now that you know what a "live" ebuild is, if you are interested, just yell. Live-svn is certainly not for everyone, but if you'd be following it if you had a conveniently automated way of doing so, or already are doing it manually, the ebuild will certainly be useful. =8^) -- 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 _______________________________________________ Pan-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/pan-users
