Re: [Pan-devel] seeing lots of problems (Re: ANN : Tabs support for article overview)

[Duncan]

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