Feb 1, 2010, 5:47 PM
Post #2 of 4
(2324 views)
Permalink
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