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

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[Dale]

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

:-)  :-)

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

[Nirbheek Chauhan]

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

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

[Dale]

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

:-)  :-)

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

[Ulrich Mueller]

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

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

[Michael Haubenwallner]

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

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

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

[Patrick Lauer]

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

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

[Duncan]

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

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[Ulrich Mueller]

>>>>> On Fri, 1 Jul 2011, William Hubbs wrote:

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

If that is sufficient for providing an upgrade path, then yes.

Ulrich

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

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]

On 11:26 Fri 01 Jul     , Nirbheek Chauhan wrote:
> 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.

In my experience, updates become massively difficult after about 6 
months unless you have deep expertise in Gentoo. You run into blocker 
after blocker after USE-flag problem after resolution failure and an 
ongoing series of confusing messages with no apparent end in sight. We 
may call it supported (and technically, we're right) but it isn't 
realistically possible for most users.

After handing over administration of about 10 systems to someone else 
with less experience in Gentoo, I still get called in about once every 
couple of months to help every time one of these weird problems comes 
up. I recommended upgrades to the new admin every 3 months, which is a 
point where nearly everything still works cleanly.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1646 bytes --]

On Fri, Jul 01, 2011 at 09:08:53AM -0500, Donnie Berkholz wrote:
> On 11:26 Fri 01 Jul     , Nirbheek Chauhan wrote:
> > 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.
> 
> In my experience, updates become massively difficult after about 6 
> months unless you have deep expertise in Gentoo. You run into blocker 
> after blocker after USE-flag problem after resolution failure and an 
> ongoing series of confusing messages with no apparent end in sight. We 
> may call it supported (and technically, we're right) but it isn't 
> realistically possible for most users.

Right. I can't tell you how many times I've seen on -user where someone
comes back after not upgrading for longer than 6 months and finds
themselves in a very tricky situation.

Since we have a council decision that says the migration path has to
exist for a year, that's what I'll follow. However, if someone waits a
year to upgrade a gentoo system, things will have changed so much that
the upgrade process will be challenging for them to say the least,
unless they know gentoo very well.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[Dale]

William Hubbs wrote:
> On Fri, Jul 01, 2011 at 09:08:53AM -0500, Donnie Berkholz wrote:
>    
>> On 11:26 Fri 01 Jul     , Nirbheek Chauhan wrote:
>>      
>>> 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.
>>>        
>> In my experience, updates become massively difficult after about 6
>> months unless you have deep expertise in Gentoo. You run into blocker
>> after blocker after USE-flag problem after resolution failure and an
>> ongoing series of confusing messages with no apparent end in sight. We
>> may call it supported (and technically, we're right) but it isn't
>> realistically possible for most users.
>>      
> Right. I can't tell you how many times I've seen on -user where someone
> comes back after not upgrading for longer than 6 months and finds
> themselves in a very tricky situation.
>
> Since we have a council decision that says the migration path has to
> exist for a year, that's what I'll follow. However, if someone waits a
> year to upgrade a gentoo system, things will have changed so much that
> the upgrade process will be challenging for them to say the least,
> unless they know gentoo very well.
>
> William
>
>    

I been using Gentoo since about 2003, old 1.4 days, and I wouldn't try 
to upgrade after six months unless there has been very few major 
changes.  I may would sync and see what it looks like but if I see 
several blockers or some major upgrade, like expat if I recall 
correctly, then it would be a fresh install for me.  So, I'm a long time 
Gentoo user and I been around the block a few times and I certainly know 
where to get help, but even with all that between my ears, I still say 
it is faster to start over.  If in say the past three months there have 
been a few major upgrades, I would do the same.  If in 9 months it has 
just been "normal" upgrades, then I would try it.  It all depends on 
what has changed and how much time it would take to work through the 
problem.

Now if you have some very complicated server setup, then that may be 
different.  At that point you would have to put in the balance what is 
easier and faster, upgrade or re-install.  Generally, emerge -ep world | 
genlop -p plus time to configure everything again versus time needed to 
work through the upgrade, which there is no certainty of.  That's the 
balance.  Having the world file and some needed files from /etc would 
make things a lot faster too.

Balance.  Just don't fall off the scale.  lol

Dale

:-)  :-)

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

[Duncan]

Duncan posted on Fri, 01 Jul 2011 11:26:58 +0000 as excerpted:

> Patrick Lauer posted on Fri, 01 Jul 2011 11:45:16 +0200 as excerpted:
> 
>> [Keeping an up and running system during a reinstall is] not as easy
>> as it could be.

> Can't disagree there. =:^)

... And upon further thought, can't disagree with the first part, 
either.  I've seen people untar a stage tarball over top and have it work 
for recovery, but that was with a generally uptodate system in any case, 
so dropping in a current stage3 generally replaced existing files.  
You're very correct about portage getting confused if the existing 
packages are outdated, since the tarball would be dropping in untracked 
files.  At least in the past, portage wouldn't unmerge glibc or the like, 
but it certainly WOULD leave the untracked cruft around.

It's not stage tarball related but I once had to deal with recovering 
from the loss of a /usr/ partition so when I loaded the backup 
partition, /usr/ and / and /var/ weren't in sync any more, meaning the 
package database was unsynced.  /That/ was an interesting thing to 
recover from, involving lots of manual equery belongs loops and tracking 
down whether orphaned files were deletable or something eselect or the 
like handled... over time as various weird bugs showed up because 
something was using the untracked crufty version instead of the new one.  
So I KNOW what the results of that unmanaged cruft can be!  (My resulting 
policy is to keep /, most of /var/, and most of /user/ on the same 
partition, everything that portage touches.  So if I have to fallback to 
backup, it might be dated, but at least portage's database will be in 
sync with what's actually installed.)

(I'd have simply skipped this to avoid the noise only it was unfinished 
business where I knew I was wrong and hadn't said so, and therefore 
bothering me greatly.  Now I can sleep properly again! =:^)

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

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

[Rich Freeman]

On Fri, Jul 1, 2011 at 4:05 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> You're very correct about portage getting confused if the existing
> packages are outdated, since the tarball would be dropping in untracked
> files.  At least in the past, portage wouldn't unmerge glibc or the like,
> but it certainly WOULD leave the untracked cruft around.

I wonder if there is a way to get around keeping cruft in the tree for
the sake of those who don't update often.

Something that comes to mind is having a binpkg repository for
everything in system - essentially a binpkg stage3.

I'll tinker with that a little, but if catalyst just uses emerge then
an easy way to generate this would be to add FEATURES=buildpkg to the
autogenerated stage3s.  Then we just need to mirror the binary
packages a little.

We should discourage users from using it except for rescue.  It would
be undesirable anyway since it would need to use stock use flags.

Rich

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

[Duncan]

Rich Freeman posted on Fri, 01 Jul 2011 16:50:28 -0400 as excerpted:

> I wonder if there is a way to get around keeping cruft in the tree for
> the sake of those who don't update often.
> 
> Something that comes to mind is having a binpkg repository for
> everything in system - essentially a binpkg stage3.

Useful idea.

One thing to keep in mind when we're talking about the download of 
historical binaries is the obligations of the GPL, etc, in that regard.  
Gentoo doesn't normally have to worry about this as it normally ships 
sources, not binaries, and for current stage tarballs, which /are/ 
binary, the sources are, pretty much by definition as Gentoo handles it, 
made available at the same time (tho there might possibly be argument 
over whether they're made available at the same place, etc, I've made no 
attempt to grok or verify the legal minutia in that regard).

But once you start shipping historical binaries, as we're talking here, 
we need to worry about EITHER keeping sources available at the same time/
place for them too, as long as they're shipped, OR keeping them available 
to be shipped upon request to ANYONE for up to three years.  Based on 
previous discussion, the make available at the same time and place clause 
is considered easier for distributions such as Gentoo to fulfill than the 
upon request for three years clause.

(That's the GPLv2 requirements as I understand them.  I don't understand 
the GPLv3 and its differences in that regard really at all... except that 
I believe the same basic idea remains valid. IANAL.  The Gentoo 
Foundation folks are the ones who probably should be tracking this. 
Etc...)

This discussion came up at least once before, some years ago, when Gentoo 
was still making available historic stage tarballs dating back to 1.4 or 
earlier, and there was some real question as to whether we were sure that 
all the required sources were still available.  I never validated whether 
action was actually taken, but the conclusion from that discussion, IIRC, 
was that the best practical action we could take would be to (1) ensure 
that we always kept corresponding sources from then on and made them 
available at the same time/place as the binaries, and (2), quit 
distributing the "historic interest" stages that there was a legitimate 
question about as to whether we could provide sources or not.

Just something to keep in mind any time the idea of public availability 
of non-current binaries, for whatever reason, comes up.  It's not all 
purely technical worries, tho fortunately, implementation of the legal 
requirements does ultimately boil down to technical details, too.

I'd opine that's one practical reason why binaries remain a definite 
secondary from Gentoo's perspective -- sources-only lessens the legal 
requirements DRAMATICALLY, both as regards the GPL, and in regard to 
patents.

Hopefully that's not a discouragement for something that I really believe 
is a great idea, but it /does/ need to be considered.

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

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

[Rich Freeman]

On Fri, Jul 1, 2011 at 5:39 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> One thing to keep in mind when we're talking about the download of
> historical binaries is the obligations of the GPL, etc, in that regard.
>...
> But once you start shipping historical binaries, as we're talking here,

Actually, I wasn't thinking about providing historical binaries - just
ones matching those in a stage3.  Binary distribution of stage3 is a
problem we already have license-wise.

The problem with just unzipping a stage3 on your system is that you
break all the package management tracking of files.  The solution I'm
proposing is to just use a binary emerge to do the exact same thing
(perhaps selectively) so that everything is package managed.

Now, this will still break anything that has an RDEPEND on a system
package with a non-standard use flag.  I suspect those kinds of issues
are going to be relatively rare.  Also, they're easily fixed.

The real big problem with an emerge -uD world on a system that is a
year old is that the toolchain and other key system packages may not
be able to update themselves all in one shot.  Maybe the new portage
doesn't run on the old python, or you have some kind of circular
situation where two toolchain packages don't build with the other's
old version.

Using a binary repository would let you get a USE-neutral clean copy
of any of that stuff installed.  There are still things that could go
wrong (mostly related to fetching/extraction/python/portage), but the
number of components that need to be working for a binary install is
much lower than for a full build.  So, I would think that it is pretty
likely that you could jump straight to a modern system if you did a
binary emerge.  Then you could do a revdep-rebuild, or even an emerge
-e system/world to really clean things up.

Maybe there is some obvious flaw in my logic here...

Rich