Re: [gentoo-user] Re: depclean wants to wipe out KDE3
On Mon, 22 Dec 2008 16:04:06 +0200, Nikos Chantziaras wrote: Why would they? /usr/kde/3.5/bin comes first in KDE 3 sessions and last in KDE 4 sessions. There's no problem at all. Not here % echo $PATH /usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i486-pc-linux-gnu/gcc-bin/4.1.2:/usr/i686-pc-linux-gnu/gcc-bin/4.3.2:/usr/kde/3.5/bin:/usr/qt/3/bin:/home/nelz/bin Maybe because you *do* use kdeprefix. Maybe it's better without it, like here, where it works ;D I get the same order on this computer, which does not have KDE4. -- Neil Bothwick Don't just read the Tagline; read the MESSAGE! signature.asc Description: PGP signature
[gentoo-user] Re: depclean wants to wipe out KDE3
Neil Bothwick wrote: On Mon, 22 Dec 2008 16:04:06 +0200, Nikos Chantziaras wrote: Why would they? /usr/kde/3.5/bin comes first in KDE 3 sessions and last in KDE 4 sessions. There's no problem at all. Not here % echo $PATH /usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i486-pc-linux-gnu/gcc-bin/4.1.2:/usr/i686-pc-linux-gnu/gcc-bin/4.3.2:/usr/kde/3.5/bin:/usr/qt/3/bin:/home/nelz/bin Maybe because you *do* use kdeprefix. Maybe it's better without it, like here, where it works ;D I get the same order on this computer, which does not have KDE4. That's because you don't have it. `echo $PATH` in a KDE3 session: /usr/kde/3.5/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/usr/qt/3/bin:/usr/games/bin `echo $PATH` in a KDE4 session: /usr/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/usr/qt/3/bin:/usr/games/bin So can we all agree now that the kdeprefix USE flag doesn't matter the least with KDE3+KDE4 and that it's only there to support multiple installations of KDE4? (Like KDE 4.0.x + 4.1.x at the same time.)
Re: [gentoo-user] Re: depclean wants to wipe out KDE3
Nikos Chantziaras wrote:
Neil Bothwick wrote:
On Mon, 22 Dec 2008 16:04:06 +0200, Nikos Chantziaras wrote:
Why would they? /usr/kde/3.5/bin comes first in KDE 3 sessions and
last in KDE 4 sessions. There's no problem at all.
Not here
% echo $PATH
/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i486-pc-linux-gnu/gcc-bin/4.1.2:/usr/i686-pc-linux-gnu/gcc-bin/4.3.2:/usr/kde/3.5/bin:/usr/qt/3/bin:/home/nelz/bin
Maybe because you *do* use kdeprefix. Maybe it's better without it,
like here, where it works ;D
I get the same order on this computer, which does not have KDE4.
That's because you don't have it.
`echo $PATH` in a KDE3 session:
/usr/kde/3.5/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/usr/qt/3/bin:/usr/games/bin
`echo $PATH` in a KDE4 session:
/usr/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/usr/qt/3/bin:/usr/games/bin
So can we all agree now that the kdeprefix USE flag doesn't matter the
least with KDE3+KDE4 and that it's only there to support multiple
installations of KDE4? (Like KDE 4.0.x + 4.1.x at the same time.)
r...@smoker / # euse -i kdeprefix
global use flags (searching: kdeprefix)
[+ C ] kdeprefix - Makes a KDE prefixed install into /usr/kde/${SLOT}
if enabled or into /usr (FHS compatible) otherwise
local use flags (searching: kdeprefix)
no matching entries found
r...@smoker / #
Dale
:-) :-)
[gentoo-user] Re: depclean wants to wipe out KDE3
Dale wrote:
Nikos Chantziaras wrote:
Neil Bothwick wrote:
On Mon, 22 Dec 2008 16:04:06 +0200, Nikos Chantziaras wrote:
Why would they? /usr/kde/3.5/bin comes first in KDE 3 sessions and
last in KDE 4 sessions. There's no problem at all.
Not here
% echo $PATH
/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i486-pc-linux-gnu/gcc-bin/4.1.2:/usr/i686-pc-linux-gnu/gcc-bin/4.3.2:/usr/kde/3.5/bin:/usr/qt/3/bin:/home/nelz/bin
Maybe because you *do* use kdeprefix. Maybe it's better without it,
like here, where it works ;D
I get the same order on this computer, which does not have KDE4.
That's because you don't have it.
`echo $PATH` in a KDE3 session:
/usr/kde/3.5/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/usr/qt/3/bin:/usr/games/bin
`echo $PATH` in a KDE4 session:
/usr/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/usr/qt/3/bin:/usr/games/bin
So can we all agree now that the kdeprefix USE flag doesn't matter the
least with KDE3+KDE4 and that it's only there to support multiple
installations of KDE4? (Like KDE 4.0.x + 4.1.x at the same time.)
r...@smoker / # euse -i kdeprefix
global use flags (searching: kdeprefix)
[+ C ] kdeprefix - Makes a KDE prefixed install into /usr/kde/${SLOT}
if enabled or into /usr (FHS compatible) otherwise
local use flags (searching: kdeprefix)
no matching entries found
r...@smoker / #
Here's what it should say:
[+ C ] kdeprefix - Makes a KDE 4 prefixed install into [...]
How I know? I don't use kdeprefix and my KDE 3 is installed in
/usr/kde/3.5 ;)
Also, if you care to look you'll see that kdeprefix is not used by any
KDE3 ebuild.
Re: [gentoo-user] Re: depclean wants to wipe out KDE3
On Tue, 23 Dec 2008 14:54:52 +0200, Nikos Chantziaras wrote: Maybe because you *do* use kdeprefix. Maybe it's better without it, like here, where it works ;D I get the same order on this computer, which does not have KDE4. That's because you don't have it. `echo $PATH` in a KDE3 session: /usr/kde/3.5/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/usr/qt/3/bin:/usr/games/bin On both computers, one with KDE4 installed and one without, /usr/bin comes before any KDE directories in my $PATH. -- Neil Bothwick I used to live in the real world, but I got evicted. signature.asc Description: PGP signature
Re: [gentoo-user] Re: depclean wants to wipe out KDE3
Nikos Chantziaras wrote:
Dale wrote:
Nikos Chantziaras wrote:
Neil Bothwick wrote:
On Mon, 22 Dec 2008 16:04:06 +0200, Nikos Chantziaras wrote:
Why would they? /usr/kde/3.5/bin comes first in KDE 3 sessions and
last in KDE 4 sessions. There's no problem at all.
Not here
% echo $PATH
/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i486-pc-linux-gnu/gcc-bin/4.1.2:/usr/i686-pc-linux-gnu/gcc-bin/4.3.2:/usr/kde/3.5/bin:/usr/qt/3/bin:/home/nelz/bin
Maybe because you *do* use kdeprefix. Maybe it's better without it,
like here, where it works ;D
I get the same order on this computer, which does not have KDE4.
That's because you don't have it.
`echo $PATH` in a KDE3 session:
/usr/kde/3.5/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/usr/qt/3/bin:/usr/games/bin
`echo $PATH` in a KDE4 session:
/usr/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/usr/qt/3/bin:/usr/games/bin
So can we all agree now that the kdeprefix USE flag doesn't matter the
least with KDE3+KDE4 and that it's only there to support multiple
installations of KDE4? (Like KDE 4.0.x + 4.1.x at the same time.)
r...@smoker / # euse -i kdeprefix
global use flags (searching: kdeprefix)
[+ C ] kdeprefix - Makes a KDE prefixed install into /usr/kde/${SLOT}
if enabled or into /usr (FHS compatible) otherwise
local use flags (searching: kdeprefix)
no matching entries found
r...@smoker / #
Here's what it should say:
[+ C ] kdeprefix - Makes a KDE 4 prefixed install into [...]
How I know? I don't use kdeprefix and my KDE 3 is installed in
/usr/kde/3.5 ;)
Also, if you care to look you'll see that kdeprefix is not used by any
KDE3 ebuild.
I subscribe to the -dev thread and if I recall correctly, KDE 3.5
installs into /usr/kde/3.5 whether kdeprefix is set or not. KDE 3.5 and
earlier always has. However, KDE 4.0 has changed and requires that flag
if you want KDE 4.* installed in /usr/kde/4.*.
So, if you are not using KDE 4.*, then it has no effect yet. If you
have it set and have both KDE 3.5 and KDE 4.0, then it will install KDE
3.5 in /usr/kde/3.5 and KDE 4.0 in /usr/kde/4.*. If you have both KDE
3.5 and KDE 4.* and it is not set, it installs KDE 3.5 in /usr/kde/3.5
and KDE 4.* in /usr.
Since the people that do the ebuilds is the same people that wrote what
the flag does, I like how you want to change what it means. If they
don't know what the flag does, nobody else likely will either. If you
disagree with what it says, go to -dev and tell them to change it or
file a bug report.
Dale
:-) :-)
Re: [gentoo-user] Re: depclean wants to wipe out KDE3
On Mon, 22 Dec 2008 02:18:27 +0200, Nikos Chantziaras wrote: OK, now I'm really curious; turns out they are NOT dependencies :P I just checked with equery and nothing depends on them. Is that normal? I mean, startkde for example is crucial to even start KDE 3 and it's not a dependency? In which case it must have been in world. If you don't want to use KDE 4.x, just convert all kde-base entries in world to use he 3.5 slot. sed -i 's/\(^kde-base.*\)/\1:3.5/' /var/lib/portage/world -- Neil Bothwick When you go to court you are putting yourself in the hands of 12 people that were not smart enough to get out of jury duty. signature.asc Description: PGP signature
Re: [gentoo-user] Re: depclean wants to wipe out KDE3
On Mon, 22 Dec 2008 03:57:22 +0200, Nikos Chantziaras wrote: And how is putting KDE4 in /usr/kde going to help in this? What difference does it make if the wrong path is chosen? Surely, it doesn't matter a bit how that path looks like if it's wrong. If a KDE4 path would come before a KDE3 path in a KDE3 session, the last thing you care about is whether that path is /usr/bin or /usr/kde/4.1/bin. Because /usr/bin will always be in your PATH, so even if you are running a KDE 3 session, KDE4 programs will be loaded. By keeping the separate,not only from one another but also from other programs, you can ensure that your PATH includes only KDE3 or KDE4 programs. -- Neil Bothwick I'm Not Sure If I'm Homosexual, Said Tom, Half In Earnest. signature.asc Description: PGP signature
Re: [gentoo-user] Re: depclean wants to wipe out KDE3
Neil Bothwick wrote: On Mon, 22 Dec 2008 03:57:22 +0200, Nikos Chantziaras wrote: And how is putting KDE4 in /usr/kde going to help in this? What difference does it make if the wrong path is chosen? Surely, it doesn't matter a bit how that path looks like if it's wrong. If a KDE4 path would come before a KDE3 path in a KDE3 session, the last thing you care about is whether that path is /usr/bin or /usr/kde/4.1/bin. Because /usr/bin will always be in your PATH, so even if you are running a KDE 3 session, KDE4 programs will be loaded. By keeping the separate,not only from one another but also from other programs, you can ensure that your PATH includes only KDE3 or KDE4 programs. So to clarify a bit more, for me at least. If you login to KDE 3.5 then /usr/kde/3.5/bin is in your path but not /usr/kde/kde/4.*. The same could be said in the reverse I assume? If you don't use the flag and login to KDE 3.5 then all the KDE 4.* stuff is in your path and anytime you try to open a KDE 3.5 app, it sees the KDE 4.* apps first? Correct? If it is, I can only imagine how confused a computer would be. I wonder if a person could change the order that those paths are searched? Could you put in a config file somewhere to search one first then the others or would that just not work well in the reverse situation? I think I am out of cents again. o~o I'm starting to see why this is so confusing to a computer now. Whew ! Dale :-) :-)
[gentoo-user] Re: depclean wants to wipe out KDE3
Dale wrote: Neil Bothwick wrote: On Mon, 22 Dec 2008 03:57:22 +0200, Nikos Chantziaras wrote: And how is putting KDE4 in /usr/kde going to help in this? What difference does it make if the wrong path is chosen? Surely, it doesn't matter a bit how that path looks like if it's wrong. If a KDE4 path would come before a KDE3 path in a KDE3 session, the last thing you care about is whether that path is /usr/bin or /usr/kde/4.1/bin. Because /usr/bin will always be in your PATH, so even if you are running a KDE 3 session, KDE4 programs will be loaded. By keeping the separate,not only from one another but also from other programs, you can ensure that your PATH includes only KDE3 or KDE4 programs. So to clarify a bit more, for me at least. If you login to KDE 3.5 then /usr/kde/3.5/bin is in your path but not /usr/kde/kde/4.*. The same could be said in the reverse I assume? If you don't use the flag and login to KDE 3.5 then all the KDE 4.* stuff is in your path and anytime you try to open a KDE 3.5 app, it sees the KDE 4.* apps first? Correct? If it is, I can only imagine how confused a computer would be. I wonder if a person could change the order that those paths are searched? Could you put in a config file somewhere to search one first then the others or would that just not work well in the reverse situation? That's already the case. /usr/bin comes first in KDE4 sessions, while /usr/kde/3.5/bin is first in KDE 3 sessions. Same goes for LDPATH.
[gentoo-user] Re: depclean wants to wipe out KDE3
Neil Bothwick wrote: On Mon, 22 Dec 2008 03:57:22 +0200, Nikos Chantziaras wrote: And how is putting KDE4 in /usr/kde going to help in this? What difference does it make if the wrong path is chosen? Surely, it doesn't matter a bit how that path looks like if it's wrong. If a KDE4 path would come before a KDE3 path in a KDE3 session, the last thing you care about is whether that path is /usr/bin or /usr/kde/4.1/bin. Because /usr/bin will always be in your PATH, so even if you are running a KDE 3 session, KDE4 programs will be loaded. Why would they? /usr/kde/3.5/bin comes first in KDE 3 sessions and last in KDE 4 sessions. There's no problem at all.
Re: [gentoo-user] Re: depclean wants to wipe out KDE3
Nikos Chantziaras wrote: Neil Bothwick wrote: On Mon, 22 Dec 2008 03:57:22 +0200, Nikos Chantziaras wrote: And how is putting KDE4 in /usr/kde going to help in this? What difference does it make if the wrong path is chosen? Surely, it doesn't matter a bit how that path looks like if it's wrong. If a KDE4 path would come before a KDE3 path in a KDE3 session, the last thing you care about is whether that path is /usr/bin or /usr/kde/4.1/bin. Because /usr/bin will always be in your PATH, so even if you are running a KDE 3 session, KDE4 programs will be loaded. Why would they? /usr/kde/3.5/bin comes first in KDE 3 sessions and last in KDE 4 sessions. There's no problem at all. Then why doesn't it work then? I'm confused. I just know that I have already put the USE flag in mine for when KDE 4 goes stable and starts moving in. I like having KDE in the place it has always been since it has worked for me so far. Yes, I read the arguments made on -dev a while ago. It didn't make sense then and it still doesn't. Dale :-) :-)
Re: [gentoo-user] Re: depclean wants to wipe out KDE3
On Mon, 22 Dec 2008 13:37:08 +0200, Nikos Chantziaras wrote: Because /usr/bin will always be in your PATH, so even if you are running a KDE 3 session, KDE4 programs will be loaded. Why would they? /usr/kde/3.5/bin comes first in KDE 3 sessions and last in KDE 4 sessions. There's no problem at all. Not here % echo $PATH /usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i486-pc-linux-gnu/gcc-bin/4.1.2:/usr/i686-pc-linux-gnu/gcc-bin/4.3.2:/usr/kde/3.5/bin:/usr/qt/3/bin:/home/nelz/bin Keeping the programs separate seems a more robust approach than hoping they will be found in the right order. I would never recommend anyone to use two KDE slots without kdeprefix. -- Neil Bothwick Dream as if you'll live forever. Live as if you'll die today. signature.asc Description: PGP signature
[gentoo-user] Re: depclean wants to wipe out KDE3
Dale wrote: Nikos Chantziaras wrote: Neil Bothwick wrote: On Mon, 22 Dec 2008 03:57:22 +0200, Nikos Chantziaras wrote: And how is putting KDE4 in /usr/kde going to help in this? What difference does it make if the wrong path is chosen? Surely, it doesn't matter a bit how that path looks like if it's wrong. If a KDE4 path would come before a KDE3 path in a KDE3 session, the last thing you care about is whether that path is /usr/bin or /usr/kde/4.1/bin. Because /usr/bin will always be in your PATH, so even if you are running a KDE 3 session, KDE4 programs will be loaded. Why would they? /usr/kde/3.5/bin comes first in KDE 3 sessions and last in KDE 4 sessions. There's no problem at all. Then why doesn't it work then? It works. It's just that this thread has gone off topic :P
[gentoo-user] Re: depclean wants to wipe out KDE3
Neil Bothwick wrote: On Mon, 22 Dec 2008 13:37:08 +0200, Nikos Chantziaras wrote: Because /usr/bin will always be in your PATH, so even if you are running a KDE 3 session, KDE4 programs will be loaded. Why would they? /usr/kde/3.5/bin comes first in KDE 3 sessions and last in KDE 4 sessions. There's no problem at all. Not here % echo $PATH /usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i486-pc-linux-gnu/gcc-bin/4.1.2:/usr/i686-pc-linux-gnu/gcc-bin/4.3.2:/usr/kde/3.5/bin:/usr/qt/3/bin:/home/nelz/bin Maybe because you *do* use kdeprefix. Maybe it's better without it, like here, where it works ;D
Re: [gentoo-user] Re: depclean wants to wipe out KDE3
On Sun, 2008-12-21 at 06:34 +0200, Nikos Chantziaras wrote: Nikos Chantziaras wrote: [...] The reason is that KDE4 is a new product and has nothing to do with KDE3 other than the name. And another reason is the problem I'm describing in this very thread which should have not been a problem if KDE4 had its own tree. Now I'm required to have non-straightforward voodoo performed to get things right just because the devs made a wrong decision. That's what SLOTS are fore. KDE4 is in it's own slot and can be installed instead of/in addition to KDE 3.5. Putting a package in a different SLOT is effectively putting it i it's own tree. $ emerge -p kde-base/kde-meta:3.5 [...] [ebuild N] kde-base/kdepim-wizards-3.5.10 USE=-debug [ebuild N] kde-base/karm-3.5.10 USE=-debug [ebuild N] kde-base/kontact-specialdates-3.5.10 USE=-debug [ebuild N] kde-base/kdepim-meta-3.5.10 USE=-pda [ebuild N] kde-base/kde-meta-3.5.10 USE=nls -accessibility $ emerge -p kde-base/kde-meta:4.1 [...] [ebuild N] kde-base/krunner-4.1.3 USE=opengl -debug -kdeprefix -xcomposite -xscreensaver [ebuild N] kde-base/kdepim-meta-4.1.3 [ebuild N] kde-base/kdebase-startkde-4.1.3 USE=-kdeprefix [ebuild N] kde-base/kdebase-meta-4.1.3 [ebuild N] kde-base/kde-meta-4.1.3 USE=-accessibility What kind of voodoo is that? In the past, Gentoo devs have spend a lot of time and effort moving split package trees under one tree (e.g. PHP). I don't see them going backwards any time soon. Another problem, this time not technical. I just don't want many of those packages in my world file. I want to use depclean and have those packages removed when the package that depends on them is also removed. The depclean feature just got useless for those packages. By definition, --depclean doesn't remove anything in the world file (or its dependencies). If you want something removed don't put it in the world file (or put something that depends on it in your world file). *You* are the controller of your world file. Nothing gets put there without your specifying so. Anyone still thinks it was a good idea to have KDE4 use the same tree with KDE3? This is was clearly a wrong decision. Workarounds are welcome. I don't think you need a work-around, just to understand how portage works. A (re-)read of the man pages should help. -a
Re: [gentoo-user] Re: depclean wants to wipe out KDE3
On Saturday 20 December 2008 14:35:13 Nikos Chantziaras wrote: Alan McKinnon wrote: On Saturday 20 December 2008 11:53:05 Nikos Chantziaras wrote: You can start by giving the relevant information, like what exactly related to kde is in world?. Chances are you only have KDE there, and emerge will probably want to nuke all but the latest SLOT. Common problems with KDE: Put 'kdeprefix' in USE and rebuild Put KDE:3.5 in world and recheck. This last one often needs to be redone recursively to get everything in world that needs to be there. I've heard that autounmask helps with this kdeprefix has nothing to do with KDE3. It's not needed. It's only needed to have many KDE4 versions at the same time. That's not true. Yes it is. http://www.gentoo.org/proj/en/desktop/kde/kde4-guide.xml#doc_chap3 This restriction does not apply to KDE 3.5 [...]. You can have a non-kdeprefix version of KDE 4.1, KDE 3.5 and a live version of KDE installed on the same system. kdeprefix is *only* for multiple KDE 4 installations. Now go back and read my post again. I'm not talking about what the docs are talking about. I'm talking about kde-3* being installed into /usr/kde/3.5 and KDE-4 being installed into /usr/ and the resulting mess that happens when you get LDPATH, PATH and various other env vars set up wrong when you start a session. With USE=-kdeprefix, KDE4 is installed into /usr/ With USE=kdeprefix, KDE4 is installed into /usr/kde/4.x Yes, and KDE3 is *always* installed in /usr/kde/3.5 no matter what. Therefore, kdeprefix is totally irrelevant here. No it is not, and you have not read my post properly. I'm not talking about the *installation* of kde-3.5 interfering with KDE-4, I'm talking about run time. I'm saying that KDE-4 co-existing with kde-3.5 is so much easier if KDE-4 is installed into /usr/kde. The net result, when co-installed with kde-3.x, is that your various *PATH variables will always have 3 before 4 or vice-versa. Which is a major pita trying to get 3 and 4 to co-exist. Try it sometime, and watch KDE-4 try to read KDE-3's config and data files. Or have KDE-4 launch konqueror-4 and always get it right every time. Has nothing to do with kdeprefix :P See above. There's only one sane way to install KDE on gentoo - always use SLOTs, always put every version in it's own directory in /usr/kde/, always add the relevant directories to PATH | LDPATH | etc at start-up. The other option is to have one, and only one, kde version at any time. You're misinformed, I think. For the reasons above :) I'll try the KDE:3.5 thingy. I wonder though why the heck I have to do this. KDE4 should have been put in its own tree. Well that's your opinion, you are entitled to it. The KDE devs don't agree though, and their three of a kind trumps your two pairs. If you are going to assert that KDE-4 SHOULD be in it's own tree, then you are going to have to present a sane argument for why, and for why the existing decision is incorrect. Just saying something should be doesn't cut the mustard in this case. The reason is that KDE4 is a new product and has nothing to do with KDE3 other than the name. And another reason is the problem I'm describing in this very thread which should have not been a problem if KDE4 had its own tree. Now I'm required to have non-straightforward voodoo performed to get things right just because the devs made a wrong decision. It would *still* be a problem. The konqueror binary is called konqueror on-disk in 3.5 and 4. If you don't set up the environment correctly, which one is going to be launched? It makes much more sense to install all versions of all DEs calling themselves KDE the same way if you have two or more of them installed. If you only have KDE-4 and do not have KDE-3*, then elect to USE kdeprefix any way that suits your needs. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: depclean wants to wipe out KDE3
On Sun, 21 Dec 2008 06:34:39 +0200, Nikos Chantziaras wrote: Another problem, this time not technical. I just don't want many of those packages in my world file. I want to use depclean and have those packages removed when the package that depends on them is also removed. The depclean feature just got useless for those packages. That's incorrect. You only need the packages you use in world, portage is clever enough to figure out which dependencies are needed by 3.5 packages. -- Neil Bothwick If this leaves a waxy buildup - on anything - I'm coming back. signature.asc Description: PGP signature
[gentoo-user] Re: depclean wants to wipe out KDE3
Neil Bothwick wrote: On Sun, 21 Dec 2008 06:34:39 +0200, Nikos Chantziaras wrote: Another problem, this time not technical. I just don't want many of those packages in my world file. I want to use depclean and have those packages removed when the package that depends on them is also removed. The depclean feature just got useless for those packages. That's incorrect. You only need the packages you use in world, portage is clever enough to figure out which dependencies are needed by 3.5 packages. But it wants to unmerge these for example: kde-base/kate kde-base/kdebase-startkde kde-base/ksmserver These were dependencies and therefore were not in my world file. If they get unmerge, things will break. KDevelop will break without Kate, and KDE 3.5 itself will break without the other two. :P
[gentoo-user] Re: depclean wants to wipe out KDE3
Nikos Chantziaras wrote: kde-base/kate kde-base/kdebase-startkde kde-base/ksmserver These were dependencies and therefore were not in my world file. If they get unmerge, things will break. KDevelop will break without Kate, and KDE 3.5 itself will break without the other two. :P OK, now I'm really curious; turns out they are NOT dependencies :P I just checked with equery and nothing depends on them. Is that normal? I mean, startkde for example is crucial to even start KDE 3 and it's not a dependency?
[gentoo-user] Re: depclean wants to wipe out KDE3
Alan McKinnon wrote: On Saturday 20 December 2008 14:35:13 Nikos Chantziaras wrote: Alan McKinnon wrote: On Saturday 20 December 2008 11:53:05 Nikos Chantziaras wrote: kdeprefix has nothing to do with KDE3. It's not needed. It's only needed to have many KDE4 versions at the same time. That's not true. Yes it is. http://www.gentoo.org/proj/en/desktop/kde/kde4-guide.xml#doc_chap3 This restriction does not apply to KDE 3.5 [...]. You can have a non-kdeprefix version of KDE 4.1, KDE 3.5 and a live version of KDE installed on the same system. kdeprefix is *only* for multiple KDE 4 installations. Now go back and read my post again. I'm not talking about what the docs are talking about. I'm talking about kde-3* being installed into /usr/kde/3.5 and KDE-4 being installed into /usr/ and the resulting mess that happens when you get LDPATH, PATH and various other env vars set up wrong when you start a session. And how is putting KDE4 in /usr/kde going to help in this? What difference does it make if the wrong path is chosen? Surely, it doesn't matter a bit how that path looks like if it's wrong. If a KDE4 path would come before a KDE3 path in a KDE3 session, the last thing you care about is whether that path is /usr/bin or /usr/kde/4.1/bin. And anyway, starting KDE3 puts the KDE3 paths first. Starting KDE4 puts the KDE4 paths first. And you don't need kdeprefix to get that behavior. With USE=-kdeprefix, KDE4 is installed into /usr/ With USE=kdeprefix, KDE4 is installed into /usr/kde/4.x Yes, and KDE3 is *always* installed in /usr/kde/3.5 no matter what. Therefore, kdeprefix is totally irrelevant here. No it is not, and you have not read my post properly. I'm not talking about the *installation* of kde-3.5 interfering with KDE-4, I'm talking about run time. I'm saying that KDE-4 co-existing with kde-3.5 is so much easier if KDE-4 is installed into /usr/kde. Doesn't look any easier to me.
Re: [gentoo-user] Re: depclean wants to wipe out KDE3
On Mon, Dec 22, 2008 at 02:18:27AM +0200, Penguin Lover Nikos Chantziaras
squawked:
Nikos Chantziaras wrote:
kde-base/kate
kde-base/kdebase-startkde
kde-base/ksmserver
These were dependencies and therefore were not in my world file. If they
get unmerge, things will break. KDevelop will break without Kate, and KDE
3.5 itself will break without the other two. :P
OK, now I'm really curious; turns out they are NOT dependencies :P I just
checked with equery and nothing depends on them. Is that normal? I mean,
startkde for example is crucial to even start KDE 3 and it's not a
dependency?
Hum, that is bizarre. I just tried emerge -pvt kde-meta, and it shows
that kde-meta depends on kdebase-meta depends on kdebase-startkde
(all version 3.5.9)
Checking all the ebuilds currently in the tree (versions 3.5.9,
3.5.10, 4.1.2 and 4.1.3), shows that all versions of kdebase-meta
depend on their corresponding versions of kdebase-startkde (they all
contain the line
=kde-base/kdebase-startkde-${PV}:${SLOT}
which picks the right slot). So something is probably broken on your
system. Check the contents of the various ebuilds for the versions you
installed to see what's wrong.
W
--
For the relative problem is one in which the relative radius vectors...from
one to the other? So, actually, I was wrong. Kepler was right after all.
~DeathMech, S. Sondhi. P-town PHY 205
Sortir en Pantoufles: up 745 days, 44 min
[gentoo-user] Re: depclean wants to wipe out KDE3
Willie Wong wrote:
On Mon, Dec 22, 2008 at 02:18:27AM +0200, Penguin Lover Nikos Chantziaras
squawked:
Nikos Chantziaras wrote:
kde-base/kate
kde-base/kdebase-startkde
kde-base/ksmserver
These were dependencies and therefore were not in my world file. If they
get unmerge, things will break. KDevelop will break without Kate, and KDE
3.5 itself will break without the other two. :P
OK, now I'm really curious; turns out they are NOT dependencies :P I just
checked with equery and nothing depends on them. Is that normal? I mean,
startkde for example is crucial to even start KDE 3 and it's not a
dependency?
Hum, that is bizarre. I just tried emerge -pvt kde-meta, and it shows
that kde-meta depends on kdebase-meta depends on kdebase-startkde
(all version 3.5.9)
Checking all the ebuilds currently in the tree (versions 3.5.9,
3.5.10, 4.1.2 and 4.1.3), shows that all versions of kdebase-meta
depend on their corresponding versions of kdebase-startkde (they all
contain the line
=kde-base/kdebase-startkde-${PV}:${SLOT}
which picks the right slot). So something is probably broken on your
system. Check the contents of the various ebuilds for the versions you
installed to see what's wrong.
I'm not using -meta packages. Many packages they pulled in was stuff I
don't wanted (like PIM). I emerged KDE packages one-by-one and went
with what got pulled in as dependencies.
Re: [gentoo-user] Re: depclean wants to wipe out KDE3
Nikos Chantziaras wrote:
Willie Wong wrote:
On Mon, Dec 22, 2008 at 02:18:27AM +0200, Penguin Lover Nikos
Chantziaras squawked:
Nikos Chantziaras wrote:
kde-base/kate
kde-base/kdebase-startkde
kde-base/ksmserver
These were dependencies and therefore were not in my world file.
If they get unmerge, things will break. KDevelop will break
without Kate, and KDE 3.5 itself will break without the other two. :P
OK, now I'm really curious; turns out they are NOT dependencies :P
I just checked with equery and nothing depends on them. Is that
normal? I mean, startkde for example is crucial to even start KDE 3
and it's not a dependency?
Hum, that is bizarre. I just tried emerge -pvt kde-meta, and it shows
that kde-meta depends on kdebase-meta depends on kdebase-startkde
(all version 3.5.9)
Checking all the ebuilds currently in the tree (versions 3.5.9,
3.5.10, 4.1.2 and 4.1.3), shows that all versions of kdebase-meta
depend on their corresponding versions of kdebase-startkde (they all
contain the line
=kde-base/kdebase-startkde-${PV}:${SLOT}
which picks the right slot). So something is probably broken on your
system. Check the contents of the various ebuilds for the versions you
installed to see what's wrong.
I'm not using -meta packages. Many packages they pulled in was stuff
I don't wanted (like PIM). I emerged KDE packages one-by-one and went
with what got pulled in as dependencies.
If he is going to use KDE as his GUI, doesn't he need to start with at
least kdebase then add onto that? On my system, kdebase brings in
startkde. If he emerges that and it gets added to the world file, would
that help with the current problem?
I only use KDE here but from what I have read you can install Konqueror
and still use some other GUI without KDE being installed and possibly no
startkde. Could this be confusing portage into thinking he is doing
this? Maybe?
Dale
:-) :-)
Re: [gentoo-user] Re: depclean wants to wipe out KDE3
On Mon, Dec 22, 2008 at 04:20:25AM +0200, Penguin Lover Nikos Chantziaras squawked: I'm not using -meta packages. Many packages they pulled in was stuff I don't wanted (like PIM). I emerged KDE packages one-by-one and went with what got pulled in as dependencies. Uh.. then what exactly were you complaining about? The only thing that depends on kdebase-startkde is kdebase-meta, at least in a standard-ish installation of KDE using the meta packages. Let me put it this way: by not installing the -meta package, you explicitly say that you think you know better than the kde devs in what makes a basic, useable, KDE desktop. And now you complain because your subset of KDE packages does not contain everything you need? Okay, all jokes aside: since you have particular wants and don't-wants with regards to the KDE packaging, I really suggest that instead of keeping all that junk in your world file, that you create your own overlay and write your own -meta ebuild. My guess is just copying the kde-meta ebuild and editting the RDEPEND variable to reflect the actual packages you want will do it. HTH, W -- Bakers trade bread recipes on a knead to know basis. Sortir en Pantoufles: up 745 days, 1:42
[gentoo-user] Re: depclean wants to wipe out KDE3
Alan McKinnon wrote: On Saturday 20 December 2008 08:27:40 Nikos Chantziaras wrote: emerge -av --depclean: kde-base/kopete selected: 3.5.10 protected: none omitted: 4.1.3 kde-base/kget selected: 3.5.10 protected: none omitted: 4.1.3 kde-base/kmenuedit selected: 3.5.10 protected: none omitted: 4.1.3 The list goes on. All those packages are in my world file. This only started happening after installing KDE 4.1.3. Another nice effect of not putting KDE4 in new portage trees but rather mixing them with KDE3? What can I do? You can start by giving the relevant information, like what exactly related to kde is in world?. Chances are you only have KDE there, and emerge will probably want to nuke all but the latest SLOT. Common problems with KDE: Put 'kdeprefix' in USE and rebuild Put KDE:3.5 in world and recheck. This last one often needs to be redone recursively to get everything in world that needs to be there. I've heard that autounmask helps with this kdeprefix has nothing to do with KDE3. It's not needed. It's only needed to have many KDE4 versions at the same time. I'll try the KDE:3.5 thingy. I wonder though why the heck I have to do this. KDE4 should have been put in its own tree.
Re: [gentoo-user] Re: depclean wants to wipe out KDE3
On Saturday 20 December 2008 11:53:05 Nikos Chantziaras wrote: You can start by giving the relevant information, like what exactly related to kde is in world?. Chances are you only have KDE there, and emerge will probably want to nuke all but the latest SLOT. Common problems with KDE: Put 'kdeprefix' in USE and rebuild Put KDE:3.5 in world and recheck. This last one often needs to be redone recursively to get everything in world that needs to be there. I've heard that autounmask helps with this kdeprefix has nothing to do with KDE3. It's not needed. It's only needed to have many KDE4 versions at the same time. That's not true. With USE=-kdeprefix, KDE4 is installed into /usr/ With USE=kdeprefix, KDE4 is installed into /usr/kde/4.x The net result, when co-installed with kde-3.x, is that your various *PATH variables will always have 3 before 4 or vice-versa. Which is a major pita trying to get 3 and 4 to co-exist. Try it sometime, and watch KDE-4 try to read KDE-3's config and data files. Or have KDE-4 launch konqueror-4 and always get it right every time. There's only one sane way to install KDE on gentoo - always use SLOTs, always put every version in it's own directory in /usr/kde/, always add the relevant directories to PATH | LDPATH | etc at start-up. The other option is to have one, and only one, kde version at any time. I'll try the KDE:3.5 thingy. I wonder though why the heck I have to do this. KDE4 should have been put in its own tree. Well that's your opinion, you are entitled to it. The KDE devs don't agree though, and their three of a kind trumps your two pairs. If you are going to assert that KDE-4 SHOULD be in it's own tree, then you are going to have to present a sane argument for why, and for why the existing decision is incorrect. Just saying something should be doesn't cut the mustard in this case. -- alan dot mckinnon at gmail dot com
[gentoo-user] Re: depclean wants to wipe out KDE3
Alan McKinnon wrote: On Saturday 20 December 2008 11:53:05 Nikos Chantziaras wrote: You can start by giving the relevant information, like what exactly related to kde is in world?. Chances are you only have KDE there, and emerge will probably want to nuke all but the latest SLOT. Common problems with KDE: Put 'kdeprefix' in USE and rebuild Put KDE:3.5 in world and recheck. This last one often needs to be redone recursively to get everything in world that needs to be there. I've heard that autounmask helps with this kdeprefix has nothing to do with KDE3. It's not needed. It's only needed to have many KDE4 versions at the same time. That's not true. Yes it is. http://www.gentoo.org/proj/en/desktop/kde/kde4-guide.xml#doc_chap3 This restriction does not apply to KDE 3.5 [...]. You can have a non-kdeprefix version of KDE 4.1, KDE 3.5 and a live version of KDE installed on the same system. kdeprefix is *only* for multiple KDE 4 installations. With USE=-kdeprefix, KDE4 is installed into /usr/ With USE=kdeprefix, KDE4 is installed into /usr/kde/4.x Yes, and KDE3 is *always* installed in /usr/kde/3.5 no matter what. Therefore, kdeprefix is totally irrelevant here. The net result, when co-installed with kde-3.x, is that your various *PATH variables will always have 3 before 4 or vice-versa. Which is a major pita trying to get 3 and 4 to co-exist. Try it sometime, and watch KDE-4 try to read KDE-3's config and data files. Or have KDE-4 launch konqueror-4 and always get it right every time. Has nothing to do with kdeprefix :P There's only one sane way to install KDE on gentoo - always use SLOTs, always put every version in it's own directory in /usr/kde/, always add the relevant directories to PATH | LDPATH | etc at start-up. The other option is to have one, and only one, kde version at any time. You're misinformed, I think. For the reasons above :) I'll try the KDE:3.5 thingy. I wonder though why the heck I have to do this. KDE4 should have been put in its own tree. Well that's your opinion, you are entitled to it. The KDE devs don't agree though, and their three of a kind trumps your two pairs. If you are going to assert that KDE-4 SHOULD be in it's own tree, then you are going to have to present a sane argument for why, and for why the existing decision is incorrect. Just saying something should be doesn't cut the mustard in this case. The reason is that KDE4 is a new product and has nothing to do with KDE3 other than the name. And another reason is the problem I'm describing in this very thread which should have not been a problem if KDE4 had its own tree. Now I'm required to have non-straightforward voodoo performed to get things right just because the devs made a wrong decision.
[gentoo-user] Re: depclean wants to wipe out KDE3
Nikos Chantziaras wrote: [...] The reason is that KDE4 is a new product and has nothing to do with KDE3 other than the name. And another reason is the problem I'm describing in this very thread which should have not been a problem if KDE4 had its own tree. Now I'm required to have non-straightforward voodoo performed to get things right just because the devs made a wrong decision. Another problem, this time not technical. I just don't want many of those packages in my world file. I want to use depclean and have those packages removed when the package that depends on them is also removed. The depclean feature just got useless for those packages. Anyone still thinks it was a good idea to have KDE4 use the same tree with KDE3? This is was clearly a wrong decision. Workarounds are welcome.
Re: [gentoo-user] Re: depclean wants to wipe out KDE3
Nikos Chantziaras wrote: Nikos Chantziaras wrote: [...] The reason is that KDE4 is a new product and has nothing to do with KDE3 other than the name. And another reason is the problem I'm describing in this very thread which should have not been a problem if KDE4 had its own tree. Now I'm required to have non-straightforward voodoo performed to get things right just because the devs made a wrong decision. Another problem, this time not technical. I just don't want many of those packages in my world file. I want to use depclean and have those packages removed when the package that depends on them is also removed. The depclean feature just got useless for those packages. Anyone still thinks it was a good idea to have KDE4 use the same tree with KDE3? This is was clearly a wrong decision. Workarounds are welcome. If you want to talk to the people that made that decision, the mailing list is gentoo-user@lists.gentoo.org and you subscribe by sending a email to gentoo-user+subscr...@gentoo.org and confirming the reply as you did to this list. I would recommend you be very clear as to why they made a wrong decision and get it right on the first try. Good luck with that. Better have your ducks in a row. Since I'm subscribed there, I get to watch. o_O Dale :-) :-)
