Ernie Schroder schreef:
> On Saturday 17 December 2005 22:57, a tiny voice compelled Richard
> Fish to write:
>
>> On 12/17/05, LostSon <[EMAIL PROTECTED]> wrote:
>>
>>> On Saturday 17 December 2005 21:17, Nick Rout wrote:
>>>
>>>> I see a lot of people seem to have upgraded to kde 3.5.
>>>>
>>>> I am currently running kde 3.4.1 (installed via kde-meta) and
>>>> stable is 3.4.3. However reports seem to be that 3.5.0 seems
>>>> good enuf to work with and I can't be bothered compiling 3.4.3
>>>> and then 3.5 later.
>>>>
>>>> Soooo, is there an easy way forward? I suspect I could enter a
>>>> large number of packages as ~x86 in
>>>> /etc/portage/package.keywords, or I could ask here if there is
>>>> an easier way.
>>>
>>> Hello Simply use
>>>
>>> ACCEPT_KEYWORDS="~x86" emerge kde
>>
>> Except the next time you want to "emerge -Duv world", it will want
>> to downgrade. Assuming you don't want a full ~x86 version, do:
>>
>> ACCEPT_KEYWORDS="~x86" emerge -p kde-meta
>>
>> This will give a list of all packages to add to
>> /etc/portage/package.keywords. You can even automate this with:
>>
>> for x in `ACCEPT_KEYWORDS="~x86" emerge -p kde-meta | awk '{ print
>> $4 }' | grep "/"` do echo "$x ~x86" >>
>> /etc/portage/package.keywords done
>
> Take it from me, do it as Richard says or you'll be in for a severe
> shock next emerge -ua world. I had to downgrade 72 packages that were
> brought in when I put ACCEPT_KEYWORDS on the command line.
>
> Wait til Holly sees this <grin>
No, no, Ernie, you've covered the meat of any warning I would give with
relation to LostSon's suggestion, but I'll say it again:
Do *not* use ACCEPT_KEYWORDS on the command line except for an explicit
'testing' situation. Either with --pretend, to see what packages are
involved, or for a single/simple unstable package that you actively are
not sure if you want to keep, for which Portage's automatic downgrade
will not be a problem (because you've checked and you don't want the
package), or for which you will immediately add the package to
/etc/portage/package.keywords (because you've checked and you do want to
keep the package in its unstable version).
There is, however, another option that people seem to forget:
WAIT.
If you run x86, you likely do so because you value stability over "cool
factor". You want to be sure it works "out-of-the-box", without a whole
lot of management froo-fraw, even if that means you don't have the
absolutely latest version of the application /today/.
People, this is not Debian. It's not as if you're going to have to wait
2 or 3 years for KDE 3.5 to migrate to the 'stable' branch. But people
seem to forget that 1) the stable and unstable branches refer to the
/*ebuilds*/, not the program itself (if the program itself was unstable,
it would be hard masked, or even all-arches-masked, or not in Portage at
all), and 2) KDE has a bloody lot of ebuilds, all of which must interact
with each other seamlessly to provide an efficient and successful
Portage experience.
So what you're testing when you run an ~arch application is the
correctness of the ebuild to compile the application properly, not the
program itself. It's not as if somebody releases an application that
doesn't compile, for Pete's sake-- but if the ebuild is wrong/flawed,
the application may not compile properly *under Gentoo*. Witness the
issue with the hard-masked version of Portage. It's hard-masked because
*major problems in the process are expected, and the result may not be
useable* (hard-masking seems to relate to both the ebuild and the final
program).
The testing branches are meant for just that-- testing. Testing of the
ebuilds, testing of the ebuilds and the applications under different
architectures (will thus-and-so program compile at all under sparc, for
example, and does the ebuild as it stands replicate the successful
compilation, if such a successful compilation is possible?), and testing
of the ebuild and the application (the 8.16.20 version of the ATI
drivers was all-arch-masked shortly after release because so many people
had problems with them -- and the problem was determined to be
upstream-- that they were deemed too dangerous for the general population).
If you want to test, fine-- but learn the proper procedures for doing
so and take responsibility for the fact that you are testing this
application with regards to the emerge process and Portage. Yes,
unmasking KDE is a difficult processs, but you're testing the package on
behalf of Gentoo, and that is not supposed to be easy. Take
responsibility for the fact that you're performing a service and 1) suck
it up; 2) pay attention to what you're doing so that you can be a good
tester and report problems to b.g.o.
If you don't want to test, then just *&$%#^* wait until those who do
report any issues that may exist (and hopefully the ebuild is
fixed/revised), or report "no issues" (basically by not submitting any
bugs against it), and the package is marked stable (or removed, as the
case may be).
It's not like the world is going to end if you don't have KDE 3.5
/today/ as opposed to two weeks from today (probably sooner, since KDE
is a high-demand package, and people will start to b**ch if it's not
stable some specified time after the well-known upstream release date).
Patience is a virtue-- and stable arch users are /supposed/ to be
virtuous (cautious in the service of those who value the certainty that
everything 'just works' above having the 'latest and greatest' the day
after it comes out).
Just my 0.58 Eurocents,
Holly
--
gentoo-user@gentoo.org mailing list
