SciFi posted on Fri, 04 Nov 2011 03:47:31 +0000 as excerpted: > I keep "good" copies of many projects in this manner. > I can very-quickly run "sudo make install" to poke _that_ build into the > usual (normal runnable) locations.
<the light dawns> Oh, OK. So you keep currently completed binary builds around, and can simply switch to whichever one and run make install to poke all the right bits into all the right places in the main system. Whereas, with the git system I described, there's only one completed binary build available at any point, and one would have to do a complete rebuild (perhaps after a suitable make clean, delete of the build dir, or whatever) to have the new version available to be installed in the first place. That makes a reasonable amount of sense, in that case, particularly if one considers the portability of the solution as well -- your solution works on any generic tarball or source control system, while the solution I described is git-specific to some degree, there's certainly similar available for other source control, but it's just that, similar, they aren't universal. So yes, on a primarily binary-based installation, your solution makes quite a bit of sense. Of course, here on Gentoo, with FEATURES=buildpkg set, the whole thing is already automated for the general version-tagged case as applies to the general system. Every package I install gets binpkged after build, with the binpkg archived and then automatically tested as the install actually occurs from the freshly archived binpkg, not the working dir used to build the package from sources. So to the extent that I choose to keep those archives around, I too can quickly reinstall whatever arbitrary version I want, for testing, etc, from the prebuilt binaries. But I don't keep the actual built sources around for that, only the installed files together with the script that installs them and some metadata (the ebuild and associated metadata as appended to the archive). Of course, the source tarballs themselves are also cached by the package management system, but separately. And that's the raw source tarballs as shipped by upstream, not the post-build sources and installed files combined. But For live-sources packages, like pan, which I rebuild on-demand after syncing from the latest git or whatever VCS, the way Gentoo's automated system works, there's only the single archive kept. It'd be reasonably trivial to create a script that appends the commit ID to the filename of the associated tarball, and hook into that script from the package manager itself (it has hooks for just such customizations), but I've not bothered doing so. Part of the reason is that I only live-track a small handful of packages and since gentoo (optionally, I have it on) integrates ccache for package building and that DRAMATICALLY speeds up rebuilds of incrementally changed sources kept in the same location, as with git builds, rebuilding a live version doesn't take /that/ much more time than installing from a binpkged tarball would, and a revert has been rare enough that it hasn't to-date been worth the trouble of further automation of the live-version- revert corner-case. Plus, as with the last time I might have reverted, with hmueller's color- coding unread-threads experiment, resulting in colors I hated about as strongly as you appear to hate pan's tabs at this point, I often track down and patch the problem (either by fixing it, or with a revert of the the offending code), which yields the added bonus of being able to continue to track other upstream changes, instead of reverting to whatever state and being stuck there until a fix is integrated upstream. And both the package manager setup and my own separate scripts (which I use for the kernel) can integrate patches dynamically if they're dropped in the appropriate location. Additionally, for the kernel using my own scripts, I can and have managed patches using git integration: create a new branch for the fix, apply the patches or revert the offending commit, use git rebase to continue to integrate that branch with upstream at every update. So I guess I just haven't had much need for tree reverts beyond the automated handling already present in my package manager for normally versioned packages, since I only live-version track a few packages, and on those, when there's a problem, I'm more likely to patch (with automatic application after initial deployment) and continue following upstream for other developments, than to want to revert and maintain at a particular commit until fixed upstream. IOW, different styles, and approaching the problem from different bases with massively different assumptions. But at least I can see where your approach comes from, now, and appreciate its value especially on primarily binary-based systems that don't have (optional) automated binary-package archiving of source-built components built-in, as my from- source-assumed system already does, here. So as I said, "<the light dawns>". =:^) -- 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-devel mailing list Pan-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-devel
