Ernie Schroder schreef:
> On Monday 12 December 2005 10:11, a tiny voice compelled Holly
> Bostick to write:
>
>>>> Ernie Schroder <[EMAIL PROTECTED]> wrote:
>>>>
>>>>> [ebuild UD] sys-devel/m4-1.4.3 [1.4.4] [ebuild
>>>>> UD] sys-devel/autoconf-wrapper-3-r1 [3.2] [nomerge ]
>>>>> app-admin/perl-cleaner-1.01 [ebuild UD]
>>>>> dev-lang/perl-5.8.6-r8 [5.8.7-r2] [ebuild UD]
>>>>> sys-devel/libperl-5.8.6-r1 [5.8.7]
>>>>
>>>
>>> Close but no cigar. I did use
>>>
>>> ACCEPT_KEYWORDS="~x86" emerge kde
>>>
>>> All of these ~x86 packages were brought in at that time
>>
>> Well, that explains it.
>>
>> For the 7 billionth time, ACCEPT_KEYWORDS= on the emerge command
>> line is a /temporary/ setting, valid /only for that emerge/.
>>
>> Portage *does not remember it* once the emerge is completed-- so as
>> far as it knows, it is only allowed to install the stable packages
>> for KDE, not the unstable.
>>
>> That is why it's trying to downgrade-- and this is why you are not
>> supposed to use ACCEPT_KEYWORDS= on the command line (because this
>> will happen, and it's a real PITA, as you see).
>
> I'm not sure I follow your logic Holly. I know exactly what
> ACCEPT_KEYWORDS on the command line does. I used it for KDE only and
> all of the kde packages are in package.keywords. One would think that
> an update would not try to downgrade packages that are depended on by
> entries in .keywords, or is portage just not that smart?
But what about everything else....?
According to you, you did
ACCEPT_KEYWORDS="~x86" emerge kde
The thing is, you've basically done an "export variable" operation.
An exported variable is valid across the entire session. It does not
persist across sessions, but it persists for all processes performed in
that shell session.
So basically every emerge you did until you started a new login shell
used ~x86 rather than x86.
The direct dependencies of this package of kde are:
Runtime Dependencies
kde-3.5.0
kde-base/kdeaddons3.5.0
kde-base/kdeadmin3.5.0
kde-base/kdeartwork3.5.0
kde-base/kdebase3.5.0
kde-base/kdeedu3.5.0
kde-base/kdegames3.5.0
kde-base/kdegraphics3.5.0
kde-base/kdelibs3.5.0
kde-base/kdemultimedia3.5.0
kde-base/kdenetwork3.5.0
kde-base/kdepim3.5.0
kde-base/kdetoys3.5.0
kde-base/kdeutils3.5.0
kde-base/kdewebdev3.5.0
accessibility kde-base/kdeaccessibility3.5.0
which you've said you have in /etc/package.keywords. Fine.
However, the deep dependencies are not, but were upgraded by the use of
ACCEPT_KEYWORDS on the command line, as Neil said:
Neil Bothwick schreef:
>
> This is exactly why you should not use ACCEPT_KEYWORDS on the command
> line. It applies to the whole emerge process, so even if KDE would
> be happy with the installed version of the dependencies, you have
> told emerge to upgrade them.
So, looking for perl-related deep dependencies, we find:
Runtime Dependencies
kdenetwork-3.5.0
dev-lang/perl
<snip of the others>
So-- kdenetwork depends on perl directly, and the kde metapackage you've
installed depends on kdenetwork.
So perl is a deep dependency of (the particular) kde (metapackage) you
have installed.
Therefore it was upgraded *temporarily* by your use of ACCEPT_KEYWORDS
on the command line (because an update became available due to the
command line option).
Libperl also upgraded by this procedure as perl depends on libperl.
Runtime Dependencies
perl-5.8.7-r3
>= sys-devel/libperl - 5.8.7
berkdb sys-libs/db
gdbm >= sys-libs/gdbm - 1.8.3
So you have upgraded libperl and perl to ~x86 by using ACCEPT_KEYWORDS
on the command line. But that doesn't really explain autoconf-wrapper,
or m4, for example. Did you perhaps do some further emerges that
upgraded autoconf or autoconf wrapper, m4, and perl-cleaner? Perhaps
emerge -u world after the emerge kde? That would have upgraded packages
that depend on the upgraded packages (perl-cleaner of course depends on
perl; autoconf-wrapper depends on autoconf, which depends on perl and
has an upgrade to ~x86; m4 depends on autoconf-wrapper).
In any case, some time must have passed and you logged off, shut down,
or in some other way you must have closed the current login session in
the term and begun another, which used the 'regular' settings read from
/etc/make.conf and /etc/portage/package.keywords, since as soon as you
did an emerge -u world in what must have been a new session, Portage saw
that a number of packages were not authorized, because it has forgotten
the exported settings from the last session.
So the affected packages emerged during the export must be downgraded to
stable.
HTH,
Holly
--
gentoo-user@gentoo.org mailing list
