[gentoo-dev] Re: rfc: deprecation of baselayout-1.x

[Duncan]

Nirbheek Chauhan posted on Fri, 01 Jul 2011 11:26:50 +0530 as excerpted:

> On Fri, Jul 1, 2011 at 11:03 AM, Dale <rdalek1967@×××××.com> wrote:
>> William Hubbs wrote:
>> As a user, if a person hasn't upgraded in about 6 months, they may as
>> well reinstall anyway.  That is usually the advice given on -user.
>>  After a year without updating, it is certainly easier and most likely
>> faster to reinstall.
>
> Except for the fact that while you upgrade, you still have a usable
> system. Reinstallation means a massive time-sink during which your
> machine is completely unusable. This is not an option for a lot of
> people.

This isn't really true.  "Reinstallation" in the sense used here, and in 
the sense that removing baselayout-1 support would require, can simply 
mean untarring a new stage-3 tarball over top of an existing system and 
going from there.

That gets one a(n) unbroken and updated base on which to rebuild.  If one 
already has their general world file and USE flags setup and is already 
reasonably familiar with Gentoo, it goes pretty fast, particularly if one 
isn't rearranging partitions, etc, as one wouldn't be if we're comparing 
to a no-reinstall, and the system remains generally functional thru most 
or all of it.

Alternatively, if one wants a clean install, one can install to a new 
chroot (probably on a different partition), keeping the existing system 
intact and up and running until the new system is ready, then rebooting 
into it, and after some basic testing to be sure it really /is/ ready, 
blowing away the old system partition.  This allows one to keep the same 
/home and data partitions, and to copy over or use for reference the old 
configuration in /etc.

I actually did something very similar to the chroot install both when 
first installing Gentoo (using an existing Mandrake system, this was 
2004), and when building the 32-bit netbook image I built on a dedicated 
32-bit image partition my main machine but transferred to a thumb-drive 
for initial boot on the netbook, and now keep updated using ssh and rsync 
over ssh.  It's not difficult, and even with the differences between the 
64-bit main machine and the netbook (image), much of the configuration 
was copied over then changed as necessary.  It would be even easier if it 
was a reinstall to a new partition on the same machine with basically the 
exact same config.

So keeping an up and running machine even with a reinstall isn't a 
problem, certainly no more of one than fighting with broken installs, 
because everything has changed out from under the existing one.

And I've done in-place upgrades to my netbook image, which doesn't get 
updated nearly as frequently as my main machine, too.  Even having gone 
thru the updates one at a time on the main machine, after about 6 months, 
it becomes *HARD* to update the existing installation, because stuff 
simply /has/ changed out from under it, and at about 8 months, probably 6 
months if I hadn't been keeping up on another machine so had already gone 
thru the process incrementally once, it really *IS* more practical to 
reinstall, generally meaning in practice, doing an in-place stage-3 
tarball extraction and an emerge --emptytree @system followed by emerge
--emptytree ~world.

> If -user is regularly giving that kind of advice, I think you guys are
> making a huge mistake.
>
> I'm not going to support this kind of max-6-month-upgrade life cycle for
> Gentoo. We're effectively driving our users away to distros like Ubuntu
> that allow you to upgrade every LTS release instead of constantly or
> every 6 months.

Perhaps so.  But really, Gentoo isn't a perfect fit for everyone and 
we're only lying to ourselves and doing a disservice to our potential 
users to pretend it is.  If people are only updating every six months or 
less frequently, then they really ought to be using a distribution 
designed for exactly that sort of upgrade scenario, and Gentoo simply 
doesn't fit the description.  It can certainly still be made to work, and 
for one-offs like the year of military duty many countries have, it's a 
good thing that it can be made to work, but it's making life (and Linux) 
more difficult than it really needs to be, if that's going to be one's 
routine update spacing, and IMO we ARE simply lying to ourselves, etc, 
pretending otherwise.  And it's hurting our regular users too, because 
time spent trying to keep year-out compatibility is time that cannot be 
spent keeping packages updated and keeping rolling updates smooth.

None-the-less, as someone else points out, the policy /is/ one year.  At 
that point an upgrade's going to be rather difficult in any case, but the 
line must be drawn somewhere, and if we're not deliberately breaking 
stuff out to a year, that makes the six-month upgrades at least 
reasonably possible.  If the policy were six months, or even say 8-9 
months, it's quite possible six-month updates would be more difficult as 
well, and I doubt anyone would sanely argue that a six-month update 
shouldn't be quite reasonable, even if a bit difficult in practice.

-- 
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