FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 07-01-2011, 05:33 AM
Dale
 
Default rfc: deprecation of baselayout-1.x

William Hubbs wrote:

All,

the time has come when baselayout-2.x and openrc are stable on all of
our architectures. That means that we should look into removing
baselayout-1 from the tree, removing support for it from our init
scripts and removing support for migration from the openrc
ebuilds.

1. we can remove baselayout-1 from the tree, I think, as soon as bug
#368597 is closed, because once that is done, all new installs should
be based on baselayout-2.x and openrc.

2. The next step is to reverse the changes we made in bug #273138 and
any other init scripts that have been reacting differently depending on
whether they were under baselayout-1 or openrc. Optionally we could
rework init scripts to take advantage of openrc specific features such
as the *_pre/post functions at this point.

Once this is completed, the init scripts in portage will not support
baselayout-1, so if anyone is still on baselayout-1 we should find a way
to encourage them to migrate -- maybe a news item? Also, we should come
up with a time window that will be published in this news item that will
mark the end of supporting migration from baselayout-1 to openrc.

3. The final step is to remove the code from the openrc ebuilds that
supports migrating from baselayout-1.x. Once we do this another news
item should be published since this is the point of no return; anyone
running a baselayout-1 based system will have to re-install to upgrade
once we drop this support.

Please discuss. Did I leave out any steps? Are there any points I have
left out besides the time window between steps 2 and 3? Should there be
a time window before removing baselayout-1? What about between steps 1
and 2? What do you consider to be a reasonable time window before we
stop supporting migration from baselayout-1 to baselayout-2/openrc? I'm
thinking on the order of a few months, but not years.

Thanks,

William




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. Almost everything will be updated and there is
usually a few upgrades that are touchy and will have to be dealt with.


My thoughts, after a year, baselayout1 could be laid to rest. At that
point, a reinstall would be the easiest and fastest anyway.


Just a users perspective. YMMV.

Dale

:-) :-)
 
Old 07-01-2011, 05:56 AM
Nirbheek Chauhan
 
Default rfc: deprecation of baselayout-1.x

On Fri, Jul 1, 2011 at 11:03 AM, Dale <rdalek1967@gmail.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.

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.


--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
 
Old 07-01-2011, 06:21 AM
Dale
 
Default rfc: deprecation of baselayout-1.x

Nirbheek Chauhan wrote:

On Fri, Jul 1, 2011 at 11:03 AM, Dale<rdalek1967@gmail.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.

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.




Well, it has been done. A while ago, if I recall this correctly,
someone hadn't updated in about a year. He tried to upgrade but ran
into issue after issue. After a couple days, he ended up reinstalling.
It just depends on what updates have come along that causes issues.


I think things are better than they used to be but sometimes, it is
faster to just reinstall and be done with it. It's either spend a day
or more dealing with problems or spending a day getting a fresh start.


As for not having a system, I have one when I do my install. I just
boot Knoppix and use it. I can use a web browser to follow the docs and
check email. It's one of many ways to install Gentoo.


It's not about what Gentoo supports, it's about what is faster, easier
or at times, both.


Dale

:-) :-)
 
Old 07-01-2011, 06:38 AM
Ulrich Mueller
 
Default rfc: deprecation of baselayout-1.x

>>>>> On Thu, 30 Jun 2011, William Hubbs wrote:

> Please discuss. Did I leave out any steps? Are there any points I
> have left out besides the time window between steps 2 and 3? Should
> there be a time window before removing baselayout-1? What about
> between steps 1 and 2? What do you consider to be a reasonable time
> window before we stop supporting migration from baselayout-1 to
> baselayout-2/openrc? I'm thinking on the order of a few months, but
> not years.

We have a policy on this, see
<http://www.gentoo.org/proj/en/council/meeting-logs/20091109-summary.txt>:

| Upgrade path for old systems
| ----------------------------
| Vote (unanimous): The ebuild tree must provide an upgrade path to a
| stable system that hasn't been updated for one year.

So the time window should be at least one year after stabilisation of
baselayout-2 and openrc.

Ulrich
 
Old 07-01-2011, 07:27 AM
Michael Haubenwallner
 
Default rfc: deprecation of baselayout-1.x

On 07/01/11 07:56, Nirbheek Chauhan wrote:
> On Fri, Jul 1, 2011 at 11:03 AM, Dale <rdalek1967@gmail.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.

I'd call myself an "affected user" in this context:
As (lazy) administrator of some servers (hardened) and desktops (stable),
both virtualbox servers and guests, as well as an x86 binhost vm for the
laptop, and the only requirement of keep-it-working, I'm doing the upgrades
somewhat seldom: up to 1.5 years, especially for the hardened servers.

As I don't care for compilation time (the servers are up 24/7), my thought
to still allow for a somewhat stable upgrade path: Regularly (twice a year?)
take a tree snapshot to keep around (infra? releng?), and provide some mechanism
(eselect?) to pick such an old snapshot instead of the current (rsync) one.
Then, run each (half-year) update within a couple of days...

Maybe the tree snapshots are there already within the live-cds: Do we aim
to provide an upgrade path from one live-cd snapshot to the next one?

/haubi/
--
Michael Haubenwallner
Gentoo on a different level
 
Old 07-01-2011, 09:25 AM
Duncan
 
Default rfc: deprecation of baselayout-1.x

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@gmail.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
 
Old 07-01-2011, 09:45 AM
Patrick Lauer
 
Default rfc: deprecation of baselayout-1.x

On 07/01/11 11:25, Duncan wrote:
> 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@gmail.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.

No. Bad Duncan. Stop breaking things badly.
Portage tends to get REALLY confused with that and usually unmerges
glibc or other funnies.

What you want is either using a binhost (like tinderbox.dev.gentoo.org)
or a chroot in which you can build the binpkgs which you can then
install with emerge -K ...

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

It's not as easy as it could be. We should figure out a reliable way to
move an old install forward ...
(I have some ideas, but it all takes time and lots of testing)

--
Patrick Lauer http://service.gentooexperimental.org

Gentoo Council Member and Evangelist
Part of Gentoo Benchmarks, Forensics, PostgreSQL, KDE herds
 
Old 07-01-2011, 11:26 AM
Duncan
 
Default rfc: deprecation of baselayout-1.x

Patrick Lauer posted on Fri, 01 Jul 2011 11:45:16 +0200 as excerpted:

>> 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.
>
> It's not as easy as it could be. We should figure out a reliable way to
> move an old install forward ...
> (I have some ideas, but it all takes time and lots of testing)

Can't disagree there. =:^)

--
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
 
Old 07-01-2011, 11:44 AM
William Hubbs
 
Default rfc: deprecation of baselayout-1.x

On Fri, Jul 01, 2011 at 08:38:38AM +0200, Ulrich Mueller wrote:
> >>>>> On Thu, 30 Jun 2011, William Hubbs wrote:
>
> > Please discuss. Did I leave out any steps? Are there any points I
> > have left out besides the time window between steps 2 and 3? Should
> > there be a time window before removing baselayout-1? What about
> > between steps 1 and 2? What do you consider to be a reasonable time
> > window before we stop supporting migration from baselayout-1 to
> > baselayout-2/openrc? I'm thinking on the order of a few months, but
> > not years.
>
> We have a policy on this, see
> <http://www.gentoo.org/proj/en/council/meeting-logs/20091109-summary.txt>:
>
> | Upgrade path for old systems
> | ----------------------------
> | Vote (unanimous): The ebuild tree must provide an upgrade path to a
> | stable system that hasn't been updated for one year.
>
> So the time window should be at least one year after stabilisation of
> baselayout-2 and openrc.

To clarify then, we can do everything except remove the migration code
from the openrc ebuilds. That step needs to wait until 28 Jun 2012
right?

William
 
Old 07-01-2011, 11:44 AM
William Hubbs
 
Default rfc: deprecation of baselayout-1.x

On Fri, Jul 01, 2011 at 08:38:38AM +0200, Ulrich Mueller wrote:
> >>>>> On Thu, 30 Jun 2011, William Hubbs wrote:
>
> > Please discuss. Did I leave out any steps? Are there any points I
> > have left out besides the time window between steps 2 and 3? Should
> > there be a time window before removing baselayout-1? What about
> > between steps 1 and 2? What do you consider to be a reasonable time
> > window before we stop supporting migration from baselayout-1 to
> > baselayout-2/openrc? I'm thinking on the order of a few months, but
> > not years.
>
> We have a policy on this, see
> <http://www.gentoo.org/proj/en/council/meeting-logs/20091109-summary.txt>:
>
> | Upgrade path for old systems
> | ----------------------------
> | Vote (unanimous): The ebuild tree must provide an upgrade path to a
> | stable system that hasn't been updated for one year.
>
> So the time window should be at least one year after stabilisation of
> baselayout-2 and openrc.

To clarify then, we can do everything except remove the migration code
from the openrc ebuilds. That step needs to wait until 28 Jun 2012
right?

William
 

Thread Tools




All times are GMT. The time now is 04:48 PM.

VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org