Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
KDE 4.3 Beta 2
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
zerojay
Veteran
Veteran


Joined: 09 Aug 2003
Posts: 1033

PostPosted: Mon Feb 07, 2005 2:41 am    Post subject: Reply with quote

truekaiser wrote:
just great, more time to be wasted for micro-management that shouldn't be.
i thought portage was to make all this esayer not harder.


If you don't want to micro-manage, you don't have to. Just emerge kde-meta and let it go.
Back to top
View user's profile Send private message
truekaiser
l33t
l33t


Joined: 05 Mar 2004
Posts: 801

PostPosted: Mon Feb 07, 2005 2:48 am    Post subject: Reply with quote

DarkStalker wrote:
truekaiser wrote:
just great, more time to be wasted for micro-management that shouldn't be.
i thought portage was to make all this esayer not harder.


If you don't want to micro-manage, you don't have to. Just emerge kde-meta and let it go.


i read the other thread. that won't be a option after kde 3.4 gives way to the next version.
Back to top
View user's profile Send private message
Lokheed
Veteran
Veteran


Joined: 12 Jul 2004
Posts: 1295
Location: /usr/src/linux

PostPosted: Mon Feb 07, 2005 3:05 am    Post subject: Reply with quote

DarkStalker wrote:
Lokheed wrote:
I like to question things rather than blindly following. From my testing KControl is an essential part of KDE, but there is a separate package for it...raises some concerns. But whatever, this whole thread isnt about defending myself...

Posted my concerns and hope the devs rethink the idea of stopping monolith builds when the time comes. It seems pointless to waste resources that could be better devoted to solidifying Gentoo, than on such trivial matters as how a DE gets installed.


Kcontrol is an essential part of KDE, you're absolutely right, but for those people out there that just want to be able to install what is needed for a KDE program, like k3b, to run in Gnome, they certainly don't need Kcontrol, do they?


Your absolutely right. But if you want to install K3b, then you dont need anything from kdebase. All you need is arts qt and kdelibs which arent being split apart, so those people see absolutely no benefit.

This split is specifically for people that want KDE as a DE installed, it has no relevance to anyone needing the libraries for other qt/kde based programs like K3b.
Back to top
View user's profile Send private message
Lokheed
Veteran
Veteran


Joined: 12 Jul 2004
Posts: 1295
Location: /usr/src/linux

PostPosted: Mon Feb 07, 2005 3:05 am    Post subject: Reply with quote

truekaiser wrote:
just great, more time to be wasted for micro-management that shouldn't be.
i thought portage was to make all this esayer not harder.


That is exactly my worry too. More time to waste on something that absolutely doesnt need it.
Back to top
View user's profile Send private message
zerojay
Veteran
Veteran


Joined: 09 Aug 2003
Posts: 1033

PostPosted: Mon Feb 07, 2005 3:23 am    Post subject: Reply with quote

truekaiser wrote:
DarkStalker wrote:
truekaiser wrote:
just great, more time to be wasted for micro-management that shouldn't be.
i thought portage was to make all this esayer not harder.


If you don't want to micro-manage, you don't have to. Just emerge kde-meta and let it go.


i read the other thread. that won't be a option after kde 3.4 gives way to the next version.


Where did you see that? I don't recall seeing anything saying that.
Back to top
View user's profile Send private message
Lokheed
Veteran
Veteran


Joined: 12 Jul 2004
Posts: 1295
Location: /usr/src/linux

PostPosted: Mon Feb 07, 2005 4:06 am    Post subject: Reply with quote

http://dev.gentoo.org/~danarmak/kde-split-ebuilds.html

"Are you going to remove the old-style (monolithic) ebuilds?

We intend to so eventually. However, there will be both monolithic and split ebuilds for all the KDE 3.4 releases."
Back to top
View user's profile Send private message
zerojay
Veteran
Veteran


Joined: 09 Aug 2003
Posts: 1033

PostPosted: Mon Feb 07, 2005 4:16 am    Post subject: Reply with quote

Yes, that's right. The monolithic ebuilds are kde, kdebase, kdenetwork, etc.. they aren't removing kde-meta, kdebase-meta, kdenetwork-meta and so on. So if you still want everything the monolithic ebuilds would give you, all you would have to do is emerge the -meta version of it which automatically pulls in all the individual packages that are a part of that module. So if you wanted all of kdenetwork before, you would just...

Code:

# emerge kdenetwork


and with the split ebuilds you would...

Code:

# emerge kdenetwork-meta


...both giving you the full kdenetwork module. What they are removing is, in this example, kdenetwork, not kdenetwork-meta, so those of you that still want to do everything in one shot with one command still can, and the rest of us that aren't interested in emerging stuff we don't use don't have to.
Back to top
View user's profile Send private message
truekaiser
l33t
l33t


Joined: 05 Mar 2004
Posts: 801

PostPosted: Mon Feb 07, 2005 4:57 am    Post subject: Reply with quote

DarkStalker wrote:
Yes, that's right. The monolithic ebuilds are kde, kdebase, kdenetwork, etc.. they aren't removing kde-meta, kdebase-meta, kdenetwork-meta and so on. So if you still want everything the monolithic ebuilds would give you, all you would have to do is emerge the -meta version of it which automatically pulls in all the individual packages that are a part of that module. So if you wanted all of kdenetwork before, you would just...

Code:

# emerge kdenetwork


and with the split ebuilds you would...

Code:

# emerge kdenetwork-meta


...both giving you the full kdenetwork module. What they are removing is, in this example, kdenetwork, not kdenetwork-meta, so those of you that still want to do everything in one shot with one command still can, and the rest of us that aren't interested in emerging stuff we don't use don't have to.


from what i read on this thread, the thread linked too here and that statement from the doc is that while they will be available they will not be suported. i am sorry but i cannot see the reason why they would want to split the one esay to use ebuild up into what 50~ seprate ones or so?
Back to top
View user's profile Send private message
moocha
Watchman
Watchman


Joined: 21 Oct 2003
Posts: 5722

PostPosted: Mon Feb 07, 2005 5:26 am    Post subject: Reply with quote

Lokheed wrote:
OT: You are living in the town I was born in. I just noticed that...I have been dying to go back there as I havent seen it since I left and I was 4 at the time...small world.

Heh. Small world indeed.
Lokheed wrote:
Anyway, sorry you find my concerns and views so offensive. You "guys" take things to far and get your backs up to the wall with the slightest dissagreement with anything the devs do or the direction Gentoo goes.

Whoever said offensive? I found them unjustifiedly alarmist and thought they came across as FUD.
Lokheed wrote:
Because I dont like the splitting of the monolith packages I completely distrust and have little faith in the devs and Gentoo itself, so therefore I should go and run off and use another distro.

Please point out where I said that. I said that you should stick with the stable line.
Please read my post before replying to it. Not going to rebuke the rest of your post, I've had enough of this flamewar.
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin
Back to top
View user's profile Send private message
zerojay
Veteran
Veteran


Joined: 09 Aug 2003
Posts: 1033

PostPosted: Mon Feb 07, 2005 6:09 am    Post subject: Reply with quote

Okay, it seems like there's a lot of confusion about what is being done, why, and what it does for us as Gentoo users. I'll try to explain as best as I can and if anyone has any questions, feel free to ask.

The way the KDE ebuilds worked in the past is one ebuild per KDE module. Let's say all you wanted to install Kopete. Kopete is a part of the kdenetwork module. (Let's assume kdenetwork's dependencies are already installed for the sake of simplicity, like kdebase, kdelibs, qt, etc...) So with the old method, you would...

Code:

# emerge -pv kdenetwork


...and portage would spit out at you...

Code:

[ebuild  N    ] kde-base/kdenetwork-3.3.2  +arts -debug -kdeenablefinal -samba -slp +ssl -wifi +xinerama 0kB


Here, Portage is telling us we would have to install the monolithic ebuild for kdenetwork. With the old method, you would have to install the whole module at once even if you had no intentions of using any of the other parts of kdenetwork. DO_NOT_COMPILE was the first way to choose what you want and didn't want within the monolithic ebuilds, however it was a dirty hack, was completely unsupported and required the user to resolve dependencies within the module on his own. If you didn't know that kopete needed another module, like libkopete, you'd have to try again and go with trial and error until you got it right. If you didn't use DO_NOT_COMPILE, you would have to compile the entire kdenetwork module for just a small piece of it, wasting time.

Now, with the new split ebuilds, if you wanted to install kopete you would...

Code:

# emerge -pv kopete

[ebuild   N   ] kde-base/kopete-3.4.0_beta2 [3.4.0_beta1] +arts -debug -kdeenablefinal -kdexdeltas +ssl +xinerama 7,046 kB


...which would make portage download the kdenetwork tarball but only install what kopete needs to run and nothing else. It already knows that it needs other modules such as libkopete so you don't have to think about that at all. Also, it takes much, much less time to emerge kopete alone than the entire kdenetwork monolithic ebuild.

But what if you actually want all of kdenetwork installed, just like you would get if you had used the old monolithic ebuilds? Instead of using...

Code:

# emerge kdenetwork
[ebuild  N    ] kde-base/kdenetwork-3.4.0_beta2  +arts -debug -kdeenablefinal -samba -slp +ssl -wifi +xinerama 0kB


...you would use...

Code:

# emerge kdenetwork-meta

[ebuild  N    ] kde-base/kppp-3.4.0_beta1  +arts -debug -kdeenablefinal -kdexdeltas +xinerama 0 kB
[ebuild  N    ] kde-base/ktalkd-3.4.0_beta1  +arts -debug -kdeenablefinal -kdexdeltas +xinerama 0 kB
[ebuild  N    ] kde-base/lisa-3.4.0_beta1  +arts -debug -kdeenablefinal -kdexdeltas +xinerama 0 kB
[ebuild  N    ] kde-base/knewsticker-3.4.0_beta1  +arts -debug -kdeenablefinal -kdexdeltas +xinerama 0 kB
[ebuild  N    ] kde-base/ksirc-3.4.0_beta1  +arts -debug -kdeenablefinal -kdexdeltas +ssl +xinerama 0 kB
[ebuild  N    ] kde-base/kdict-3.4.0_beta1  +arts -debug -kdeenablefinal -kdexdeltas +xinerama 0 kB
[ebuild  N    ] kde-base/kdenetwork-filesharing-3.4.0_beta1  +arts -debug -kdeenablefinal -kdexdeltas +xinerama 0 kB
...
(Rest of the list snipped, post is getting long enough as is.)


Using the *-meta ebuilds works just the same way the old monolithic ones do, essentially. The only real problem with using the -meta ebuilds is that some time will be wasted because each ebuild will make ./configure and the other nessessary pre-compile stuff (autoconf, etc...) run once for each ebuild instead of once for all in one shot. This eats up a little extra time, though nowhere near the 20% more time that was reported earlier in this thread, even on my PII 400mhz.

So what's the main advantage of using a kdenetwork-meta ebuild instead of the old kdenetwork monolithic one? Well, let's continue with our Kopete example. Say a security fix is released for Kopete. With the older style ebuild you would end up having to do this:

Code:

# emerge -uDp world

[ebuild  U    ] kde-base/kdenetwork-3.3.2-r1  +arts -debug -kdeenablefinal -samba -slp +ssl -wifi +xinerama


Portage would download the entire new kdenetwork tarball and would recompile ALL of kdenetwork all over again. That's an awful lot of time wasted just for one part of the module to be updated. What about with the split ebuilds?

Code:

# emerge -uDp world

[ebuild     U ] kde-base/kopete-3.4.0_beta2-r1 [kopete-3.4.0_beta2] +arts -debug -kdeenablefinal -kdexdeltas +ssl +xinerama 7,046 kB


Portage would download the new tarball (or perhaps just a patch to the original one) and would compile kopete and only Kopete, saving you a lot of time. I'm sure I'm not the only one that dreaded KDE security updates that made us pretty much recompile all of KDE for just a few one-liner fixes. Thanks to the new split ebuilds, those days are far in the past.

So let's take a quick look at the pros and cons of each method.

Monolithic ebuilds (Example: kdenetwork - being phased out)

Pros:

    autoconf. configure and friends only need to be run once for the entire tree, saving some time.


Cons:

    Wanting only a small portion of the entire module was impossible (or possible with a hack as well as some trial and error).
    Security updates require you to recompile the entire module, perhaps several of them.
    Lots of wasted time compiling portions of the module you have no intentions of using.


Split ebuilds (Examples: kdenetwork-meta, kopete, ksirc, etc... - starting with KDE 3.4)

Pros:

    Allows you full control over what parts of a module will be installed, complete with dependency resolution within the module.
    Security updates require you to only recompile the affected portions of the module.
    No time wasted compiling portions you don't need, want or will ever use.


Cons:

    Each individual part of the module will need autoconf and friends to be rerun wasting a little bit of time.


Only the monolithic ones will be phased out. The new split ebuilds (-meta) will be fully supported by the Gentoo KDE team.

I hope this post is able to sum up what the hubbub is about and clear up some of the confusion here. I for one can say that the newer style ebuilds are excellent and will be better for everyone in the long-run. caleb, danarmak and the rest of the Gentoo KDE team have done an amazing job on making this new system flexible and usable for everyone.
Back to top
View user's profile Send private message
truekaiser
l33t
l33t


Joined: 05 Mar 2004
Posts: 801

PostPosted: Mon Feb 07, 2005 6:24 am    Post subject: Reply with quote

what no simple
Code:

emerge kde

to get the whole thing if you wanted it?

interesting so just a few people whining about compile times for kde get what they want at the cost of people who already did the senseable thing and compiled kde when they wern't useing the computer, oh thats right this is can incress compiling times by as much as 30%.(acroding to many posts in the offical thread about this) Even at that, before i consider this a fair deal i would like to see them do the same thing with both gnome and openoffice, requireing those who want the whole thing(which are obviously in the minority) to do more.
Back to top
View user's profile Send private message
zerojay
Veteran
Veteran


Joined: 09 Aug 2003
Posts: 1033

PostPosted: Mon Feb 07, 2005 6:30 am    Post subject: Reply with quote

truekaiser wrote:
what no simple
Code:

emerge kde

to get the whole thing if you wanted it?


To emerge all of KDE in one shot with the new split ebuilds you would use...

Code:

# emerge kde-meta
Back to top
View user's profile Send private message
zerojay
Veteran
Veteran


Joined: 09 Aug 2003
Posts: 1033

PostPosted: Mon Feb 07, 2005 6:33 am    Post subject: Reply with quote

truekaiser wrote:

interesting so just a few people whining about compile times for kde get what they want at the cost of people who already did the senseable thing and compiled kde when they wern't useing the computer, oh thats right this is can incress compiling times by as much as 30%.(acroding to many posts in the offical thread about this) Even at that, before i consider this a fair deal i would like to see them do the same thing with both gnome and openoffice, requireing those who want the whole thing(which are obviously in the minority) to do more.


You're assuming that everyone has a PC that KDE would compile on in about 8-10 hours. For some of us, it's a lot more. Around 35 hours for a full KDE install here, so these ebuilds really make a huge difference.
Back to top
View user's profile Send private message
truekaiser
l33t
l33t


Joined: 05 Mar 2004
Posts: 801

PostPosted: Mon Feb 07, 2005 6:44 am    Post subject: Reply with quote

DarkStalker wrote:
truekaiser wrote:

interesting so just a few people whining about compile times for kde get what they want at the cost of people who already did the senseable thing and compiled kde when they wern't useing the computer, oh thats right this is can incress compiling times by as much as 30%.(acroding to many posts in the offical thread about this) Even at that, before i consider this a fair deal i would like to see them do the same thing with both gnome and openoffice, requireing those who want the whole thing(which are obviously in the minority) to do more.


You're assuming that everyone has a PC that KDE would compile on in about 8-10 hours. For some of us, it's a lot more. Around 35 hours for a full KDE install here, so these ebuilds really make a huge difference.


how does this help you though? it will incress compileing time so you will be spending more time compiling or in this case trying to get kde to work in a way it was not ment to be used. if they realy wanted to help you they would of just made a binary package.
Back to top
View user's profile Send private message
Lokheed
Veteran
Veteran


Joined: 12 Jul 2004
Posts: 1295
Location: /usr/src/linux

PostPosted: Mon Feb 07, 2005 6:45 am    Post subject: Reply with quote

Slow down there DarkStalker. First let me ask a few questions. Where did you get this information from? Is this data you yourself accumulated from what you have seen and heard or this all based on real evidence? I ask because you were wrong about users saving space and time if they wanted to say only install K3b because as we discussed, you only need kdelibs and qt which are not going to be split.

Second you pick a bad example. Kopete was available as a seperate package outside of kdenetwork all along.

Third you dont fairly assess the severity of splitting up kdebase into some 200 packages.

What if I dont want kcheckpass kdcop knetattach kfind kappfinder kdm khelpcenter klipper kpager ksysguard pics ktip kxkb nsplugins ark. Am I going to have to play hop skotch and jump around the kdebase meta ebuild by installing everything one by one? Using the DO_NOT_COMPILE options, I can specify a single line and they wont be installed. What will happen with the meta ebuild if I selective choose not to install something. Will I have to just leave them out and enter the other 150+ ebuilds I do want? Are they going to set USE Flags for every single KDEBASE component in the meta ebuild?

I could care less if the DO_NOT_COMPILE option isnt supported by Gentoo. Its a KDE thing, not a Gentoo thing so why should they support it?

My major concern is how its decided what can be installed and what cant? Can I simply install qt, kdelibs and konqueror and have a fully functioning KDE? What is the limit? Will I have to waste my time testing that? Filing bug reports and recompiling and playing paste the tail on the donkey with ebuilds? So am I going to be forced to do that? I can answer the last question.

truekaiser, I am just glad I am not alone here...
Back to top
View user's profile Send private message
zerojay
Veteran
Veteran


Joined: 09 Aug 2003
Posts: 1033

PostPosted: Mon Feb 07, 2005 6:49 am    Post subject: Reply with quote

truekaiser wrote:
DarkStalker wrote:
truekaiser wrote:

interesting so just a few people whining about compile times for kde get what they want at the cost of people who already did the senseable thing and compiled kde when they wern't useing the computer, oh thats right this is can incress compiling times by as much as 30%.(acroding to many posts in the offical thread about this) Even at that, before i consider this a fair deal i would like to see them do the same thing with both gnome and openoffice, requireing those who want the whole thing(which are obviously in the minority) to do more.


You're assuming that everyone has a PC that KDE would compile on in about 8-10 hours. For some of us, it's a lot more. Around 35 hours for a full KDE install here, so these ebuilds really make a huge difference.


how does this help you though? it will incress compileing time so you will be spending more time compiling or in this case trying to get kde to work in a way it was not ment to be used. if they realy wanted to help you they would of just made a binary package.


It helps me a great deal. I pick what packages I want to compile and compile those only. My entire KDE install, including the added overhead for each ebuild, came to a little less than 20 hours. I don't know where you get the idea that this "gets kde to work in a way it was not meant to be used", because this is exactly how it was meant to be used.
Back to top
View user's profile Send private message
truekaiser
l33t
l33t


Joined: 05 Mar 2004
Posts: 801

PostPosted: Mon Feb 07, 2005 6:49 am    Post subject: Reply with quote

Quote:
truekaiser, I am just glad I am not alone here...


ditto. i am glad i am not the only one here who doesn't see this as a good thing.
Back to top
View user's profile Send private message
Lokheed
Veteran
Veteran


Joined: 12 Jul 2004
Posts: 1295
Location: /usr/src/linux

PostPosted: Mon Feb 07, 2005 6:55 am    Post subject: Reply with quote

Here is my nightmare coming true. So decided to play around with kdebase-meta. The first package it wants to install is kdebase-l10n. I dont want that, how do I get rid of it? Honestly even the monolithic ebuild didnt want to install all the locales which weigh in at 22+MB.

That seems like a real loose notion of getting more streamline.

With the split, it looks like you have two choices. One you can use the meta ebuild and install EVERYTHING and I do mean EVERYTHING

or

You are forced to selectively enter some 150+ ebuilds one by one...

I am just getting more upset the more I look into this. This is without a doubt ludicrous. Tell me I missed something and that you can pull out ebuilds you dont want from the new meta ebuilds...otherwise I dont see ANY improvement here and on top of that you are going to stop supporting the standard releases???
Back to top
View user's profile Send private message
truekaiser
l33t
l33t


Joined: 05 Mar 2004
Posts: 801

PostPosted: Mon Feb 07, 2005 7:03 am    Post subject: Reply with quote

Quote:
It helps me a great deal. I pick what packages I want to compile and compile those only. My entire KDE install, including the added overhead for each ebuild, came to a little less than 20 hours. I don't know where you get the idea that this "gets kde to work in a way it was not meant to be used", because this is exactly how it was meant to be used.


kde was not programed around gentoo's meta ebuild system. the do_not_compile is the offical way for a similar means. and as Lokheed pointed out this will be come either all or nothing. the old way was at least trimed down by removing locations not commonly used. so your choice becomes with this dumb idea to either waste more time then before by installing lituraly every package for kde under the sun or spend a day or two wading though 150~ odd ebuilds decideing what you do and do not want. talk about forceing micromanagement. if i wanted that i would of done lfs or slackware.
Back to top
View user's profile Send private message
zerojay
Veteran
Veteran


Joined: 09 Aug 2003
Posts: 1033

PostPosted: Mon Feb 07, 2005 7:06 am    Post subject: Reply with quote

Lokheed wrote:
Slow down there DarkStalker. First let me ask a few questions. Where did you get this information from? Is this data you yourself accumulated from what you have seen and heard or this all based on real evidence?


Real evidence from first hand use of the new 3.4 ebuilds myself.

Lokheed wrote:
I ask because you were wrong about users saving space and time if they wanted to say only install K3b because as we discussed, you only need kdelibs and qt which are not going to be split.


I picked a bad example there.

Lokheed wrote:

Second you pick a bad example. Kopete was available as a seperate package outside of kdenetwork all along.


That ebuild hasn't been in portage for a long time. Regardless, all the information I posted using Kopete as an example will work the same way for anything else in KDE.

Lokheed wrote:

Third you dont fairly assess the severity of splitting up kdebase into some 200 packages.

What if I dont want kcheckpass kdcop knetattach kfind kappfinder kdm khelpcenter klipper kpager ksysguard pics ktip kxkb nsplugins ark. Am I going to have to play hop skotch and jump around the kdebase meta ebuild by installing everything one by one? Using the DO_NOT_COMPILE options, I can specify a single line and they wont be installed. What will happen with the meta ebuild if I selective choose not to install something. Will I have to just leave them out and enter the other 150+ ebuilds I do want? Are they going to set USE Flags for every single KDEBASE component in the meta ebuild?


All you need to do is run...

Code:

# emerge -pv kdebase-meta


Take a look at the list and type in the ones you want.

Code:

# emerge -pv kcheckpass klipper... etc.


Lokheed wrote:

I could care less if the DO_NOT_COMPILE option isnt supported by Gentoo. Its a KDE thing, not a Gentoo thing so why should they support it?


Actually, it is a Gentoo thing and was something that the KDE ebuild maintainers came up with as a stopgap until they could get the split ebuilds done.

Lokheed wrote:

My major concern is how its decided what can be installed and what cant? Can I simply install qt, kdelibs and konqueror and have a fully functioning KDE? What is the limit? Will I have to waste my time testing that? Filing bug reports and recompiling and playing paste the tail on the donkey with ebuilds? So am I going to be forced to do that? I can answer the last question.


This is how you would do that. This is on my box.. with the 3.4.0b2 ebuilds (which aren't installed because the tarballs aren't ready yet). I also already have QT emerged so that's why it doesn't show up on the dependency list. Also, there is no meta build for kdelibs.

Code:

bash-2.05b# emerge -pv konqueror

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild     U ] kde-base/arts-3.4.0_beta2 [3.4.0_beta1] +alsa +arts -artswrappersuid -debug +esd -hardened -jack -kdeenablefinal +mad +oggvorbis +xinerama 964 kB
[ebuild     U ] kde-base/kdelibs-3.4.0_beta2 [3.4.0_beta1] +alsa +arts +cups -debug -doc +jpeg2k -kdeenablefinal -kerberos -openexr +spell +ssl +tiff +xinerama 16,269 kB
[ebuild     U ] kde-base/kdebase-applnk-3.4.0_beta2 [3.4.0_beta1] +arts -debug +java -kdeenablefinal -kdexdeltas +xinerama 22,048 kB
[ebuild     U ] kde-base/kcminit-3.4.0_beta2 [3.4.0_beta1] +arts -debug +java -kdeenablefinal -kdexdeltas +xinerama 0 kB
[ebuild     U ] kde-base/kcontrol-3.4.0_beta2 [3.4.0_beta1] +arts -debug -ieee1394 +java -kdeenablefinal -kdexdeltas +opengl* +ssl +xinerama 0 kB
[ebuild     U ] kde-base/libkonq-3.4.0_beta2 [3.4.0_beta1] +arts -debug +java -kdeenablefinal -kdexdeltas +xinerama 0 kB
[ebuild     U ] kde-base/konqueror-3.4.0_beta2 [3.4.0_beta1] +arts -debug +java -kdeenablefinal -kdexdeltas +xinerama 0 kB

Total size of downloads: 39,282 kB
bash-2.05b#                                   


As you can see there, the ebuilds are already smart enough to pull in just what is needed. Stuff like arts is listed because I have it in my USE flags. Everything it needs will be compiled for you, including QT, only portions of kdebase and kdelibs required by konqueror and yes, you should have a functional KDE on your hands. (Made a mistake here, actually you will have a fully functioning Konqueror that you could run on other windowmanagers.) No, you generally won't have to deal with bug reports or any of the other garbage because the ebuilds are at a release level right now.

Lokheed wrote:

truekaiser, I am just glad I am not alone here...


I used to feel the same way about the split ebuilds as you guys do until I decided to use them. Believe me, this is going to be a lot better than you think.
Back to top
View user's profile Send private message
zerojay
Veteran
Veteran


Joined: 09 Aug 2003
Posts: 1033

PostPosted: Mon Feb 07, 2005 7:14 am    Post subject: Reply with quote

All I'm saying here is give the new split ebuilds a chance. If you don't like it once you've given it a shot at KDE 3.4 release, talk to caleb and the other KDE maintainers. If it's enough of a problem, they might keep around the monolithic ebuilds.
Back to top
View user's profile Send private message
zerojay
Veteran
Veteran


Joined: 09 Aug 2003
Posts: 1033

PostPosted: Mon Feb 07, 2005 7:18 am    Post subject: Reply with quote

If you want a full working KDE environment using the split ebuilds with the bare minimum, you can use...

Code:

# emerge -pv kdebase-startkde

bash-2.05b# emerge -pv kdebase-startkde

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild     U ] kde-base/arts-3.4.0_beta2 [3.4.0_beta1] +alsa +arts -artswrappersuid -debug +esd -hardened -jack -kdeenablefinal +mad +oggvorbis +xinerama 964 kB
[ebuild     U ] kde-base/kdelibs-3.4.0_beta2 [3.4.0_beta1] +alsa +arts +cups -debug -doc +jpeg2k -kdeenablefinal -kerberos -openexr +spell +ssl +tiff +xinerama 16,269 kB
[ebuild     U ] kde-base/kwin-3.4.0_beta2 [3.4.0_beta1] +arts -debug +java -kdeenablefinal -kdexdeltas +xinerama 22,048 kB
[ebuild     U ] kde-base/ksmserver-3.4.0_beta2 [3.4.0_beta1] +arts -debug +java -kdeenablefinal -kdexdeltas +xinerama 0 kB
[ebuild     U ] kde-base/kreadconfig-3.4.0_beta2 [3.4.0_beta1] +arts -debug +java -kdeenablefinal -kdexdeltas +xinerama 0 kB
[ebuild     U ] kde-base/kpersonalizer-3.4.0_beta2 [3.4.0_beta1] +arts -debug +java -kdeenablefinal -kdexdeltas +xinerama 0 kB
[ebuild     U ] kde-base/kdebase-pam-4 [3.4.0_beta1] 0 kB
[ebuild     U ] kde-base/kcheckpass-3.4.0_beta2 [3.4.0_beta1] +arts -debug +java -kdeenablefinal -kdexdeltas +pam +xinerama 0 kB
[ebuild     U ] kde-base/kdebase-applnk-3.4.0_beta2 [3.4.0_beta1] +arts -debug +java -kdeenablefinal -kdexdeltas +xinerama 0 kB
[ebuild     U ] kde-base/kcminit-3.4.0_beta2 [3.4.0_beta1] +arts -debug +java -kdeenablefinal -kdexdeltas +xinerama 0 kB
[ebuild     U ] kde-base/kcontrol-3.4.0_beta2 [3.4.0_beta1] +arts -debug -ieee1394 +java -kdeenablefinal -kdexdeltas +opengl* +ssl +xinerama 0 kB
[ebuild     U ] kde-base/kdm-3.4.0_beta2 [3.4.0_beta1] +arts -debug +java -kdeenablefinal -kdexdeltas +pam +xinerama 0 kB
[ebuild     U ] kde-base/libkonq-3.4.0_beta2 [3.4.0_beta1] +arts -debug +java -kdeenablefinal -kdexdeltas +xinerama 0 kB
[ebuild     U ] kde-base/kdesktop-3.4.0_beta2 [3.4.0_beta1] +arts -debug +java -kdeenablefinal -kdexdeltas +xinerama 0 kB
[ebuild     U ] kde-base/ksplashml-3.4.0_beta2 [3.4.0_beta1] +arts -debug +java -kdeenablefinal -kdexdeltas +xinerama 0 kB
[ebuild     U ] kde-base/kdebase-startkde-3.4.0_beta2 [3.4.0_beta1] +arts -debug +java -kdeenablefinal -kdexdeltas +xinerama 0 kB

Total size of downloads: 39,282 kB
bash-2.05b#


But that's pretty much the BARE minimum. Kicker isn't included even.

So Lokheed, to answer your previous question correctly, you would use...

Code:

# emerge kdebase-startkde konqueror
Back to top
View user's profile Send private message
Herring42
Guru
Guru


Joined: 10 Mar 2004
Posts: 373
Location: Buckinghamshire

PostPosted: Mon Feb 07, 2005 8:20 am    Post subject: Reply with quote

Is it just me, or are most of the source files for kde-3.4-beta2 missing?

I can't find arts-1.3.92.tar.bz2 on any mirrors. (Amongst a long list of others).
Back to top
View user's profile Send private message
zerojay
Veteran
Veteran


Joined: 09 Aug 2003
Posts: 1033

PostPosted: Mon Feb 07, 2005 8:24 am    Post subject: Reply with quote

Herring42 wrote:
Is it just me, or are most of the source files for kde-3.4-beta2 missing?

I can't find arts-1.3.92.tar.bz2 on any mirrors. (Amongst a long list of others).


All of them are purposely missing. The tarballs are currently in testing at KDE and will be released within a week, most likely.
Back to top
View user's profile Send private message
Q-collective
Advocate
Advocate


Joined: 22 Mar 2004
Posts: 2070

PostPosted: Mon Feb 07, 2005 9:56 am    Post subject: Reply with quote

DarkStalker wrote:
truekaiser wrote:
what no simple
Code:

emerge kde

to get the whole thing if you wanted it?


To emerge all of KDE in one shot with the new split ebuilds you would use...

Code:

# emerge kde-meta

Says who? To emerge gnome or xfce you also just do
Code:
emerge gnome

or
Code:
emerge xfce4

I don't get were you have the -meta from?
(And yes, gnome and xfce4 are both metabuilds)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum