| 1 |
tetSU <tetsucceed@×××××.com> posted |
| 2 |
9d94abf00901290201p731a54adta1f4b600446b9124@××××××××××.com, excerpted |
| 3 |
below, on Thu, 29 Jan 2009 10:01:14 +0000: |
| 4 |
|
| 5 |
> Hi all. |
| 6 |
> |
| 7 |
> Im wondering... Why openrc package blocks "udev-133" and |
| 8 |
> "module-init-tools" packages? |
| 9 |
> |
| 10 |
> # ACCEPT_KEYWORDS="~amd64" emerge -pv openrc |
| 11 |
> |
| 12 |
> These are the packages that would be merged, in order: |
| 13 |
> |
| 14 |
> Calculating dependencies... done! |
| 15 |
|
| 16 |
> [ebuild U ] sys-apps/baselayout-2.0.0 [1.11.14-r3] USE="-build |
| 17 |
> (-bootstrap%) (-static%) (-unicode%)" 23 kB [?=>0] |
| 18 |
|
| 19 |
> [ebuild N ] sys-apps/openrc-0.4.2 USE="ncurses pam -debug |
| 20 |
> -unicode" 142 kB [0] |
| 21 |
|
| 22 |
> [blocks B ] <sys-fs/udev-133 ("<sys-fs/udev-133" is blocking |
| 23 |
> sys-apps/openrc-0.4.2) |
| 24 |
|
| 25 |
> [blocks B ] <sys-apps/module-init-tools-3.2.2-r2 |
| 26 |
> ("<sys-apps/module-init-tools-3.2.2-r2" is blocking |
| 27 |
> sys-apps/openrc-0.4.2) |
| 28 |
|
| 29 |
> [blocks B ] <sys-apps/sysvinit-2.86-r11 |
| 30 |
> ("<sys-apps/sysvinit-2.86-r11" is blocking sys-apps/openrc-0.4.2) |
| 31 |
|
| 32 |
Simple enough really. You apparently missed the < symbols. It's |
| 33 |
blocking older versions as it assumes features only available in the |
| 34 |
newer versions. |
| 35 |
|
| 36 |
Really, it's somewhat surprising that ~arch packages work as well as they |
| 37 |
do on a stable system, as they often assume comparably new and therefore |
| 38 |
~arch versions of other packages, not the comparative sometimes ancient |
| 39 |
history that's the latest keyword stable version. |
| 40 |
|
| 41 |
Basically what has happened is is that due to the somewhat unique way |
| 42 |
Gentoo handles initscripts, as openrc has evolved, often the initscripts |
| 43 |
and other Gentoo specific config files found in other packages evolve |
| 44 |
more or less in tandem. Because openrc is still in development in ~arch, |
| 45 |
the changes in other packages' initscripts and config files necessary to |
| 46 |
support it happen in the ~arch/testing versions as well. They won't need |
| 47 |
to be backported to earlier now-stable versions because the now ~arch |
| 48 |
versions will be stabilized either in parallel with openrc when it goes |
| 49 |
stable, or before it. Thus, people wishing to test the still ~arch |
| 50 |
openrc need the versions of packages with initscripts that match, and |
| 51 |
many of them are still ~arch as well. Thus the blocks, tho some may be |
| 52 |
missed as it's generally assumed that people running ~arch are running |
| 53 |
~arch, not stable, and testing is normally done on that basis, with the |
| 54 |
exception being arch-testing for the stable keyword when the maintainer |
| 55 |
asks that a package be stabilized and immediately before it gets that |
| 56 |
keyword, if nothing goes wrong. |
| 57 |
|
| 58 |
I really don't understand these folks who run partly stable systems. |
| 59 |
Either run stable, and be content with versions sometimes /years/ out of |
| 60 |
date, or run ~arch. Mixing the two is IMO asking for trouble. Yes, |
| 61 |
there may be very occasional exceptions due to hardware support, but I |
| 62 |
can't see openrc being in that category, and even then, if someone is |
| 63 |
planning to run sometimes years outdated stable, they really should check |
| 64 |
that the hardware they're looking at is supported that far back, before |
| 65 |
they get it. Otherwise... bite the bullet and go with ~arch. That's my |
| 66 |
opinion. |
| 67 |
|
| 68 |
-- |
| 69 |
Duncan - List replies preferred. No HTML msgs. |
| 70 |
"Every nonfree program has a lord, a master -- |
| 71 |
and if you use the program, he is your master." Richard Stallman |
Archives