[gentoo-dev] Re: i have an idea ! (erescue)

[Duncan]

David Stanek posted <20050516015654.GA7890@×××××××××××××××××××××××.net>,
excerpted below,  on Sun, 15 May 2005 21:56:54 -0400:

> On Sun, May 15, 2005 at 06:12:13PM -0700, John Myers wrote:
>> On Sunday 15 May 2005 16:41, david stanek wrote:
>> > Add an option to emerge, --backup or something similar, that will
>> > automatically run quickpkg.
>>
>> If you set FEATURES="buildpkg", portage automatically makes binary
>> packages for you. No need to add new support.
>
> That would build a binary package for the potentially broken package.
> What it would need to do is build a binary package of the existing
> merged package. So a user can recover from a botched upgrade.

I think Myers' point was that if "buildpkg" is set, the system soon builds
up a history of /multiple/ versions back of any particular package.  Thus,
if any new emerge or remerge borks the system (hmm, interesting term,
that, particularly at this moment, but then, this isn't supposed to be a
political list so enough of that, just a nod to the heritage...), it's
normally fairly easy to quickly recover to a fully working system by just
emerging the binpkg, going back as necessary to a known working version,
taking a step back if it was a remerge and you just borked the previously
working current version.

That of course brings me to /my/ point, that buildpkg is a very useful
thing to have, certainly with toolchain packages, even if the system is
space or otherwise limited enough that it's not a desirable option overall.

Thus, my suggestion.  Why not create a second feature, toolchain-buildpkg,
I'm calling it here for purposes of developing the suggestion, that's on
by default, as contrasted to the normal buildpkg being off by default. 
The Gentoo Handbook would then of course be modified to cover it and
mention why Gentoo recommends that it stay on.  Portage would then always
buildpkg anything rescue-critical, including portage itself, gcc,
binutils, coreutils, python, etc.  Don't forget glibc (which would of
course need put in place from a LiveCD, one's "emergency" copy of the root
partition, etc).

As mentioned here, tar and bzip2 would be special cases, because while
one can untar a package directly over the current filesystem if portage
(or python) itself breaks, without tar and bzip2, one is somewhat hosed
unless one uses the resources of a backup rootfs or liveCD.  Perhaps
building them static by default would be a good idea, as well as including
them in the toolchain-buildpkg list.

With such a feature, and with it on by default, another make.conf
parameter would then be useful as well.  Call it binver-depth, and set
binver-depth=3 in make.globals.  Then, when three versions of the binpkg
are reached, it would delete the oldest one as it created a new one, thus
leaving two presumably known working backups at all times, even if the
newest version it just created fails.  0 would special-case to unlimited,
of course, since we already have the feature as a toggle.  As a bonus, one
could then make the normal buildpkg feature follow binver-depth as well,
since the code would already be there, or create two separate binver-depth
vars so users can control toolchain binver-depth separately from normal
binver-depth, if desired.

I believe this solution has the merit of requiring the least new code,
since we already have the normal buildpkg feature in place and tested. 
The only new code would be that to control the toolchain package option
separate from the others, which should be easy to add, and the rotate
functionality (or make it a cron script similar to logrotate), which would
be nice but isn't an absolute "must".

Optionally, we could simply change the default of the buildpkg feature to
"on", along with appropriate coverage in the usual places (GWN, the forums
and user list, the Gentoo home page, and naturally, the Gentoo Handbook,
for new users).  That wouldn't require /any/ new portage code, altho
again, a binpkg-rotate cron script would be rather useful.

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@g.o mailing list