[gentoo-amd64] Re: udev/baselayout mess?

[Duncan]

Raffaele BELARDI posted on Mon, 01 Feb 2010 14:41:01 +0100 as excerpted:

> What's up??? udev/baselayout was working fine before the copy to the new
> HD, what happened? Any hints?

This isn't going to help you much, but it'll give you some background and 
explanation for why things are as they are ATM.

baselayout-1 is now /quite/ old and crufty -- basically no upstream for 
several years as upstream has moved on to baselayout-2 and openrc.  
baselayout-2 and openrc are the way forward, and gentoo has wanted to 
stabilize, but until recently, they were changing fast enough that it was 
difficult to stabilize anything.  Additionally, there's quite some changes 
in config between the two, and the speed up upstream changes meant that 
effectively, people were going to have to go thru at least two painful 
upgrades, one to get on baselayout-2/openrc, plus, eventually, another to 
get to wherever they ended up once upstream began to stabilize a bit.

Of course, updating all the initscripts is a decent amount of work for the 
gentoo devs as well, plus writing up good upgrade guides and changing all 
the other documentation that would have to be changed, and it was just 
very difficult to get everybody synced enough to stabilize on anything, 
because the upstream target was moving so fast.

So until quite recently, baselayout-1 continued to get just enough gentoo 
maintenance to keep it working for the stable users, while baselayout-2/
openrc moved farther and farther ahead, first as hard-masked for testing, 
then as ~arch.  baselayout-2/openrc, meanwhile, continued to advance, with 
various other boot related packages staying in some form of sync for those 
wanting to try baselayout-2/openrc, tho often using upstream deprecated 
methods.  And anyone trying to do the upgrade on their own, looking for 
documentation, had to look in multiple different places for it, including 
the comments in the config files themselves, various bugs on bugzilla, 
sometimes comments on the dev list, sometimes asking here, on user, on the 
forums, or on irc, and sometimes filing their own bugs.  It was certainly 
nothing like the nicely organized all-in-one-place upgrade guides that 
gentoo tends to have before such major changes go stable!

All that has changed recently, upstream has realized it has to stabilize 
things a bit in ordered to provide a stablization target for gentoo and 
anyone else trying to use it, the various deprecated interfaces other 
packages are using have been brought up to the current state, and 
documentation, including a brand new upgrade guide, is updated and about 
ready to roll-out.

But meanwhile, the poor stable users have been getting ever further 
behind, and recently, with the big push to stabilize baselayout-2/openrc, 
it's possible bugs relating to stable baselayout-1 aren't getting the 
attention they used to, as it's likely not going to be supported for that 
long (relatively) after baselayout-2/openrc stabilizes, anyway, because 
it /is/ so old and crufty.

Also meanwhile, all the ~arch and even sometimes masked package users like 
me, that typically answer queries like this about stuff, since we've been 
thru it before... we've been on baselayout-2/openrc for so long that we've 
forgotten most of what we used to know about baselayout-1!  Additionally, 
once baselayout-2 and openrc were in ~arch, a lot of the bugs ~arch users 
would usually see first, report, and get fixed, now hit stable users 
directly, because they're the only ones still stuck on the several years 
outdated baselayout-1, and thus the only ones experiencing bugs with it!

So here's the deal.  Unfortunately, there's not much help I can give about 
baselayout-1 -- it's just way tooo crufty and outdated.  Such is the way 
of stable, but it's even worse now, because the gap is so great, both in 
time and in method/application/config.  Perhaps someone else can help, or 
perhaps you can continue to keep the new udev masked until baselayout-2/
openrc stabilizes -- hopefully soon now, as the bugs are literally being 
closed by the day!

Alternatively, you can decide to try package.keywording baselayout-2, 
openrc, possibly udev, and maybe other boot related packages as necessary 
to get good baselayout-2/openrc support.  I believe the upgrade guide is 
in general ready, and you can test it.  As you upgrade to the new 
versions, again you'll be running stuff that us ~arch users are running, 
and will thus be far more likely to be able to help with.

The caveat is that it's a BIG upgrade.  Be prepared to spend a few hours 
reading about the changes and sloughing thru all those config updates.  
But once it's done and working, you'll be good to go and won't have to 
worry about it when the stabilization /does/ come, as you'll already be 
updated.  

Just either only package.keyword specific package versions, or be ready to 
comment/delete the lines when the stabilization does come, as I expect 
there'll be another round of ~arch packages coming then, now without the 
huge gap between them and stable that there is now, but still unstable and 
needing tested before stabilization.

For stable users who decide not to do the baselayout-2/openrc 
package.keywording at this time, preferring to stick with stable thru the 
big stabilization coming up, be aware that it /is/ coming, and that the 
upgrade /is/ going to be a big one and take some time to work thru, just 
as the big xorg or major version X environment (kde/gnome/xfce/etc) 
changes do.  But I don't believe it'll be as huge a jump and as big a 
problem as the kde-3 to kde-4 jump was, at least.  That was HUGE, and took 
multiple days (even weeks, a month or two, before things were working, 
alternatives found, etc, to my satisfaction) to process. for folks like me 
that tend to use many of the extended features, at least.

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