Hello,
On Sat, 13 Aug 2016, Jörg Schaible wrote:
>my system is still KDE 4 with the help of kde-sunset.
I don't use that repo yet, but I've copied the KDE4 stuff (relevant
for me) into my local overlay.
>However, I face an endless loop installing kactivitymanagerd. The
>package has been in group kde-base for KDE 4 and so it is in
>kde-sunset. However in central portage tree it has been moved to
>group kde-plasma. The annoying part is now, that portage is
>constantly moving with each sync the installed
>kde-base/kactivitymanagerd-4.13.3-r1 into group kde-plasma with the
>result that portage tries to install kde-
>base/kactivitymanagerd-4.13.3-r1 as new package. Which fails, because
>portage detects that some install files already exist. So I have to
>uninstall kde-plasma/kactivitymanagerd-4.13.3-r1 and let portage
>install again kde-base/kactivitymanagerd-4.13.3-r1 until the next
>sync.
Same here.
>How can I stop portage from moving the package into another group?
First of all: the odd thing is that kactivitymanagerd seems to be
optional at runtime (e.g. kate runs without it, but might miss some
"activities" features). So be bold and just
# emerge --unmerge kde-plasma/kactivitymanagerd kde-base/kactivitymanagerd
and wait for stuff to "not work". It is only a runtime dependency of
kactivities after all ;) kate e.g. links to that kactivities lib, but
if you don't use that stuff, you won't actually need the
kactivitymanagerd daemon. I guess [0].
But a stopgap workaround for emerge that works here: add this
"dummy-package" to your local overlay /usr/local/portage [*]:
====
# mkdir -p /usr/local/portage/kde-plasma/kactivitymanagerd
# cd /usr/local/portage/kde-plasma/kactivitymanagerd
# cat <<'EOF' > kactivitymanagerd-4.13.3-r1.ebuild
EAPI="5"
DESCRIPTION="KDE4 Activity Manager Daemon dummy ebuild"
KEYWORDS="amd64 ~arm ~ppc ~ppc64 x86 ~x86-fbsd ~amd64-linux ~x86-linux"
SLOT="4/4.13"
DEPEND="=kde-base/kactivitymanagerd-${PVR}"
EOF
# repoman -v manifest
# chown -cR portage.portage /usr/local/portage
====
(adjust the portage user as neccessary)
The KEYWORDS are from the kde-base ebuild, the rest is the bare minimum.
Huh, just now I wonder if a link would work... Nope. A simple symlink
kde-plasma/kactivitymanagerd/kactivitymanagerd-4.13.3-r1.ebuild ->
../../kde-base/kactivitymanagerd/kactivitymanagerd-4.13.3-r1.ebuild
does not work[**].
So, with the above dummy package:
====
# emerge --unmerge kde-plasma/kactivitymanagerd kde-base/kactivitymanagerd
[..]
# emerge --with-bdeps y --pretend -t kde-base/kactivitymanagerd
Calculating dependencies ..... done!
[ebuild N ] kde-base/kactivitymanagerd-4.13.3-r1 USE="(-aqua)"
# emerge --with-bdeps y --pretend -t kde-plasma/kactivitymanagerd
Calculating dependencies . ... ... done!
[ebuild N ] kde-plasma/kactivitymanagerd-4.13.3-r1
[ebuild N ] kde-base/kactivitymanagerd-4.13.3-r1 USE="(-aqua)"
# emerge --with-bdeps y --pretend -t kactivitymanagerd
[..trimming..]
[ Results for search key : kactivitymanagerd ]
* kde-base/kactivitymanagerd
Latest version available: 4.13.3-r1
Latest version installed: [ Not Installed ]
Description: KDE Activity Manager Daemon
* kde-plasma/kactivitymanagerd
Latest version available: 4.13.3-r1
Latest version installed: [ Not Installed ]
Description: KDE4 Activity Manager Daemon dummy ebuild
[..]
!!! The short ebuild name "kactivitymanagerd" is ambiguous. Please specify
!!! one of the above fully-qualified ebuild names instead.
# emerge --with-bdeps y kde-plasma/kactivitymanagerd
[..]
====
That's the way I like it ;)
It also quietens 'emerge @world' and 'eix kactivitymanagerd' like
thus:
====
# eix kactivitymanagerd
[I] kde-base/kactivitymanagerd [1]
Available versions: (4) 4.13.3-r1:4/4.13
{aqua}
Installed versions: 4.13.3-r1:4/4.13(09:43:13 PM 08/13/2016)(-aqua)
Homepage: https://www.kde.org/
Description: KDE Activity Manager Daemon
[I] kde-plasma/kactivitymanagerd
Available versions:
(4) 4.13.3-r1:4/4.13[1]
(5) [m]5.6.5 [m](~)5.7.3
{debug}
Installed versions: 4.13.3-r1:4/4.13[1](07:02:42 AM 08/14/2016)
Homepage: https://www.kde.org/
Description: System service to manage user's activities, track the
usage patterns etc.
[1] "local" /usr/local/portage
Found 2 matches
====
Hah, I even faked an update "kde-plasma/kactivitymanagerd-5.7.3-r1"
and it seems to work as intended, i.e. to break the cycle
-> install kde-base/kactivitymanagerd:4
-> update
-> kde-base/kactivitymanagerd:4 gone and kde-plasma/kactivitymanagerd:4
apparently installed
-> emerge wants kde-plasma/kactivitymanagerd:5
I guess the "magic move" of the installed kactivitymanagerd:4 from
kde-base/ to kde-plasma/ is caused by some weird eclass arcanities.
====
# emerge --with-bdeps y --pretend kde-plasma/kactivitymanagerd:5
[..]
[ebuild NS #] kde-plasma/kactivitymanagerd-5.7.3-r1:5::gentoo
[4.13.3-r1:4/4.13::local] USE="-debug" 79 KiB
# emerge --with-bdeps y --pretend kde-plasma/kactivitymanagerd
[..]
[ebuild R ] kde-plasma/kactivitymanagerd-4.13.3-r1:4/4.13::local 0 KiB
====
The dummy-kde-plasma/-ebuild seems to break that odd behaviour ;) I
guess it'll get sorted out over time.
HTH,
-dnh
[0] I don't use KDE, but do use quite a lot of KDE apps like k3b,
kaffeine, various games, and whatnot.
[*] ==== /etc/portage/repos.conf/local.conf ====
[local]
location = /usr/local/portage
masters = gentoo
auto-sync = no
priority = 99
====
[**] with just a symlink (plus Manifest):
# emerge --with-bdeps y --pretend -t kde-plasma/kactivitymanagerd
Calculating dependencies ....... done!
[nomerge ] kde-plasma/kactivitymanagerd-5.7.3:5::gentoo
[4.13.3-r1:4/4.13.3::local] USE="-debug"
[blocks b ] kde-plasma/kactivitymanagerd:4
("kde-plasma/kactivitymanagerd:4" is blocking
kde-plasma/kactivitymanagerd-5.7.3)
[uninstall ] kde-plasma/kactivitymanagerd-4.13.3-r1:4/4.13.3::local
[..]
or
# emerge --with-bdeps y --pretend -t kde-plasma/kactivitymanagerd:4
Calculating dependencies ...... done!
!!! All ebuilds that could satisfy "kde-plasma/kactivitymanagerd:4" have been
masked.
!!! One of the following masked packages is required to complete your request:
- kde-plasma/kactivitymanagerd-4.13.3-r1::local (masked by: invalid: SLOT:
invalid value: '', SLOT: undefined)
--
It is practically impossible to teach good programming to
students that have had a prior exposure to BASIC: as potential
programmers they are mentally mutilated beyond hope of
regeneration. -- Edsger Wybe Dijkstra
