Please do not remove support for monolithic ebuilds in the future. I, myself, have no problems managing them as they are (monolithic) and do not wish to spend erronious amounts of time micro-managing my Desktop Environment in the future. Please consider supporting and releasing KDE as it is meant to be, as it is meant to be by their respective developers. KDE was designed this way and I am not apposed to the split, but I feel it should also still be supported as it was originally intended too, in monolithic builds. There is nothing wrong with them from an install point of view and many of us have learned to manage them quite nicely with the DO_NOT_COMPILE option. Please leave in this option and do not remove it as this would be no different than closed source, restricting something on no solid foundation. There is nothing physically wrong with the monolithic ebuilds. To remove support for them because some people favour this way, is not much of a solid reason. Thank you. Reproducible: Always Steps to Reproduce: 1. 2. 3.
If you are interested (and not already done), please read this doc: http://www.gentoo.org/doc/en/kde-split-ebuilds.xml It will explain more things than me. If a lot of users wants to use monolithics ebuilds we won't remove them. But remember that the monolithics ebuilds has some problems and we are working to make the splitted one as faster as the monolothics ones. > Please consider supporting and releasing KDE as it is meant to be, as it is meant to be by their respective developers. KDE was designed this way and I am not apposed to the split, but I feel it should also still be supported as it was originally intended too, in monolithic builds. This isn't quite right. kde developers use this form because there are so many programs with a lot of interdependencies between them and putting them in groups is very logical and the unique way to develop them in an easy way. But please remember that DO_NOT_COMPILE was born for totally other reasons and its use in the monolitich ebuilds is not supported by us and it's totally illogical. If you want to use it I don't understand why you don't want to use the monolithics ebuilds. Do you know that they can live both aside. Like kdebase-monolithic and other splitted ebuilds from kdepim for example.
I agree, please keep the monolithic ebuilds. I want to use both on my system, split and monolithic. Portage was supposed to make micro managing a linux system easier. Figuring out which of the `ls /usr/portage/kde-base/ | wc -l` 388 packages I need is not making it easier. I, like many can see that split ebuilds are a good thing, but please leave the monolithic ones so that we can pick and choose whether to use split or monolithic ebuilds depending on our needs. The -meta packages are not a good answer in my opinion. Speed is one reason but patching the sources becomes harder for us in that we have to locate the appropriate ebuild to insert the epatch line. Further, if we don't use the -meta packages and install individual ebuilds, we'll always wonder whether we're missing functionality because a new feature has made it into KDE and has been split into an ebuild we don't have installed. This isn't making gentoo easier to use. Please consider supporting the monolithic ebuilds through kde 4.
Re: Lokheed: > do not wish to spend erronious amounts of time micro-managing my Desktop > Environment in the future. Why would you need to micromanage it, or manage it at all? I'm not sure what you mean by managing here, but if you emerge kde-meta, you'll get precisely the same thing you get by emerging kde. > Please consider supporting and releasing KDE as it is meant to be, as it is > meant to be by their respective developers. This is becoming some kind of urban myth. Please point me to the kde.org devs saying this is how KDE is 'meant to be'. AFAIK most other distros also have per-app packages, and I haven't heard the upstream KDE devs complain. (Not to mention that a lot of them work for those distros, and set the policy there. They're not hurrying to make monolithic packages.) > There is nothing wrong with them from an install point of view and many of > us have learned to manage them quite nicely with the DO_NOT_COMPILE option. DO_NOT_COMPILE doesn't work. Period. I'm going to add a FAQ entry about it to the split ebuilds doc, then add a huge red warning to that damnable gentoo-wiki.com page I found just now. If they're going to instruct users in evil, they should leave kde@g.o a note... (http://gentoo-wiki.com/HOWTO_Selectively_Install_KDE_Programs) > Please leave in this option and do not remove it as this would be no > different than closed source, restricting something on no solid foundation. There is no functionality in the monolithic ebuilds that the split ones don't have. Imagine I put in a move instruction in the updates file, moving all monolithic ebuilds to the -meta ones. Why should you care? > To remove support for them because some people favour this way, is not much > of a solid reason. It's because it takes us more manpower to support both sets of ebuilds.
Re: Richard: > I want to use both on my system, split and monolithic. Why? > Portage was supposed to make micro managing a linux system easier. Figuring > out which of the `ls /usr/portage/kde-base/ | wc -l` 388 packages I need is > not making it easier. If you can't figure it out, use the -meta ebuilds and you won't have lost anything. > The -meta packages are not a good answer in my opinion. Speed is one reason We're going to try to make the speed nearly equal by the time kde4 is here. > but patching the sources becomes harder for us in that we have to locate the > appropriate ebuild to insert the epatch line. I'm sorry, but that doesn't at all hard to me. If you don't know what ebuild uses file foo/bar/baz.c, grep for 'foo' in kde-base/*/*.ebuild. If there are more than two or three results, it's probably a dir like kdeaddons/konq-plugins and you should grep for 'foo/bar'. Also, almost all ebuilds have the same name as a single toplevel subdir of a kde tarball. E.g. the konqueror ebuild maps to kdebase/konqueror. A lot lot easier than, say, making that patch to begin with. > Further, if we don't use the -meta packages and install individual ebuilds, > we'll always wonder whether we're missing functionality because a new feature > has made it into KDE and has been split into an ebuild we don't have > installed. So install the meta ebuilds. What are you complaining about? We're giving you extra choice. You don't have to use the new feature of installing only some of the ebuilds.
Whats the point of asking people to make a post if they would like support for the monolithic builds here if all we get are these types of responses. Its quite apparent that you guys (Gentoo devs) have made up your minds and arent taking anyones plee to support the monolithic builds past 3.4. KDE was meant to be released as a monolithic build because thats whats available to the public. What are the split ebuilds using? Are there sources for konqueror, klipper, and kcontrol that I missed while surfing the kde ftp servers? Arent the new split ebuilds downloading the same kdebase that the monolithic ebuild gets? Now for my major problem, micro-management. If I want to install klipper and konqueror, how many packages is that? What about all the kioslave packages? What about the fact that KDE needs kcontrol to function and I dont install it? Using "emerge kde-meta" is not an option as I dont want all of kde. So I am left with trying to manage the other 150+ ebuilds because I want to omit some of them, like khelpcenter, and khotkeys. What about the other vague ebuilds. What is the kfile ebuilds all about? Will I need that? You guys have split it up into way to many packages and if I dont want to install one, that renders kde-meta completely useless. Using the DO_NOT_COMPILE option atleast allowed me to remove what I wanted and just run "emerge kdebase". Now I have to decypher 150+ ebuilds? Whatever I say here, I am sure its going to go in one ear and out the other. The sheer magnitude of trying to manage kde installs is far worse than anything I could have imagined. You guys (Gentoo devs) have done a poor job splitting them and to say you arent going to support the "official" builds is, well, I cant really think of the words. All distros (Debian for example) that split the packages still offer the original monolithic build. I fail to see how the release of kdebase is an urban myth. THAT IS THE PROPER WAY IT SHOULD BE RELEASED BECAUSE THATS WHATS AVAILABLE FROM KDE.ORG. How can that NOT be the proper way to release it? As I said above, what do the split ebuilds use? THEY ALL USE KDEBASE dont they? If they dont, then I apologize for my ignorance. I am sick of arguing. Like I said before. Its apparent that the monolithic ebuild WONT be supported unless we get sheer numbers in favour of them. A few people like myself and Richard wont make much of a difference. All you devs seem to take these comments personally as if you programmed KDE. I am not saying there isnt promise for base but my concerns are: Removing certain packages in kdebase will cause ill effects. Kcontrol is one of them, yet you have it as a selective package...what will happen if I install it without kcontrol? Have you guys done testing on what can be removed and what is absolutely necessary for the proper functioning of KDE? Two is the mangagement sucks. Its ALL, and I mean ALL, or nothing. If you dont use kde-meta, then you are stuck decypher the hundreds of packages yourself with 0 documentation and 0 descriptions of the packages...what is essential and what can be safely removed. Are those not legitimate concerns? All this adds extra time and headache on a system that was fine to begin with. There is no distro out there that doesnt offer kdebase whether or not they offer split packages...
> All distros (Debian for example) that split the packages still offer the original monolithic build. Where is it. It nothing more that our kdebase-meta... > I fail to see how the release of kdebase is an urban myth. THAT IS THE PROPER WAY IT SHOULD BE RELEASED BECAUSE THATS WHATS AVAILABLE FROM KDE.ORG. How can that NOT be the proper way to release it? As I said above, what do the split ebuilds use? THEY ALL USE KDEBASE dont they? If they dont, then I apologize for my ignorance. Your last phrase is right: what you said don't have any sense. > Removing certain packages in kdebase will cause ill effects. Kcontrol is one of them, yet you have it as a selective package...what will happen if I install it without kcontrol? Have you guys done testing on what can be removed and what is absolutely necessary for the proper functioning of KDE? Two is the mangagement sucks. Its ALL, and I mean ALL, or nothing. This doesn't have sense too. I really think that you don't have any little idea on how the split work. Have you read the docs that I suggest on comment #1 ??? > KDE was meant to be released as a monolithic build because thats whats available to the public. What are the split ebuilds using? Are there sources for konqueror, klipper, and kcontrol that I missed while surfing the kde ftp servers? Arent the new split ebuilds downloading the same kdebase that the monolithic ebuild gets? As before... > I am sick of arguing. Like I said before. Its apparent that the monolithic ebuild WONT be supported unless we get sheer numbers in favour of them. A few people like myself and Richard wont make much of a difference. All you devs seem to take these comments personally as if you programmed KDE. I program for kde (kdebluetooth and some patches) ;-) > If you dont use kde-meta, then you are stuck decypher the hundreds of packages yourself with 0 documentation and 0 descriptions of the packages...what is essential and what can be safely removed. 0 description? They're all there for every ebuild! And you are free to post patches to improve them and the docs. Remember that this is a community based distro. I don't work for you or for anything other, I (and I think all the other gentoo's devs) do this because I want to make gentoo and the OpenSource software better every day. So I only accepts good and constructive suggestions, not this kind of nosense rants. Why don't you really help us instead of offending our work?
Thats a wonderful constructive comment you made. You seem to be a mature adult with a level head and you certainly. You have answered non of my questions with anything more than insults. Why did you even bother posting? I will NOT turn this into a flame post. If you cant take criticism like an adult, then I suggest you take a few deep breaths and hit the close button on your browser. It also feels me with comfort to know that you are spearheading the split based on the comments you made here. Here is something you should do well to learn: "Convictions are more dangerous enemies of truth than are lies." - Nietzsche
There's absolutely no reason to force us to support unsplitted and splitted ebuilds forever. It's pointless extra work for us. >There is nothing wrong with them from an install point of view and many of us have learned to manage them quite nicely with the DO_NOT_COMPILE option. Please leave in this option and do not remove it as this would be no different than closed source, restricting something on no solid foundation. Even though it has been said often enough, I do it once again: DO_NOT_COMPILE does not work for several reasons and was never supported.
Hi Dan, thank you for responding. I wish to use kdebase monolithic because it saves time and I've used a heavily patched kdebase ebuild for awhile. The same goes with the kdepim. I do not however use the full kdemultimedia package so the split builds are great for me. That is why I wish to use both. Now every other point I have made you have suggested the -meta ebuilds. I don't like the -meta ebuilds but as you say, by KDE 4 you'll have the speed sorted out. Patching is harder for me, I didn't say it'd be harder for you. Thank you for the `grep` line. And to your last sentance: > So install the meta ebuilds. What are you complaining about? What the fuck? According to the doc *you* fucking wrote (http://dev.gentoo.org/~danarmak/kde-split-ebuilds.html) it offers a link asking me to tell you the reasons why I prefer the monolithic ebuilds over the split ones. I do so and now you ask me why I'm complaining? >> "If you prefer the monolithic ebuilds over the split ones, please tell us your reasons." In any case, I thank you for your comments. I will continue to use the monolithic ebuilds through KDE 3.4 and hopefuly my opinion will change in time for KDE 4.
I am extremely curious why meta ebuilds for kdebase, and so one werent made with local USE flags that can be set to remove each component exactly like the split would. This would also send 300+ ebuilds to 9+ to maintain. Why was this route not taken?
Re: Lokheed #5 > Whats the point of asking people to make a post if they would like support for > the monolithic builds here if all we get are these types of responses. I've been answering all your questions with a lot of patience. This kind of ranting isn't helping. > Its > quite apparent that you guys (Gentoo devs) have made up your minds and arent > taking anyones plee to support the monolithic builds past 3.4. What's wrong with making up our minds? We're still willing to hear you out and consider your points. > KDE was meant to be released as a monolithic build because thats whats available > to the public. Maybe KDE was also 'meant' to be used in LFS? What's available to the general public is the distros' packages, which aren't monolithic. I'll repeat this one last time: KDE.org devs aren't complaining about what they meant, so you don't have a right to, either. Stick to what _you_ mean. > If I want to install klipper and konqueror, how many packages is that? Two. > What about all the kioslave packages? What about them? They're not related to one another. And they don't even come in per-kioslave packages, but rather in big ones like kdemultimedia-kioslaves. > What about the fact that KDE needs > kcontrol to function and I dont install it? What do you mean by 'KDE needs'? If you emerge kde, you'll get kcontrol. If some specific ebuild's missing a dep on kcontrol, file a bug about that. > Using "emerge kde-meta" is not an option as I dont want all of kde. So how are the monolithic ebuilds any better? No, DO_NOT_COMPILE doesn't work, and isn't an answer. > What about the other vague ebuilds. What > is the kfile ebuilds all about? Will I need that? File a bug about better description strings. File one about better ebuild names if you feel like it. > All distros (Debian for example) that split the packages still offer the > original monolithic build. http://packages.debian.org/unstable/kde/kdebase says: KDE Base metapackage. This package depends on the minimum number of packages to provide a simple yet fully functional KDE desktop. Exactly the same as our kdebase-meta ebuild. Show me the distros that aren't like this.
> What the fuck? According to the doc *you* fucking wrote > (http://dev.gentoo.org/~danarmak/kde-split-ebuilds.html) it offers a link asking > me to tell you the reasons why I prefer the monolithic ebuilds over the split > ones. I do so and now you ask me why I'm complaining? >> "If you prefer the monolithic ebuilds over the split ones, please tell us your reasons." In any case, I thank you for your comments. I will continue to use the monolithic ebuilds through KDE 3.4 and hopefuly my opinion will change in time for KDE 4.
Oops sorry, pasted wrong text. Meant to write this: re Richard #9: > Patching is harder for me, I didn't say it'd be harder for you. Thank you > for the `grep` line. If you're applying the same patch to everything derived from kdebase, you could also edit kde-meta.eclass like this: if [ "$KMNAME" == "kdebase" ]; then PATCHES="$PATCHES foo" fi Or you could edit kde-meta_src_unpack/compile/install functions, etc. HTH. It's true that massive patching on the part of users isn't what ebuilds are designed for - you tend to slip into using overlay dirs, which can make it hard to import all upstream's changes... I agree this is an issue of sorts, but it's an issue for so few people that I'm still in favour of removing the monolithic ebuilds. > And to your last sentance: > > So install the meta ebuilds. What are you complaining about? Look again at what I responded to. My meaning was that the monolithic and split ebuilds are the same in this respect: they both make sure you have all current and future packages installed. You don't have to install separate split ebuilds. Therefore, even if we remove the monolithic ebuilds from portage, you won't lose any functionality. Installing separate split ebuilds does mean, as you said, that you may need to keep track of what new ebuilds appear in new versions of kde. If you don't want to pay that price, stick with the -meta ebuilds and nothing will change (wrt tracking new apps) compared to your situation today.
re: Lokheed #10: the problem with this solution is that we'd need to either: - Add 350 local use flags to every existing profile's make.defaults, to make them on by default. We're not allowed to. There was a thread on gentoo-dev just two days ago to this effect. Or: - Use no* flags (eg nokonqueror). But no* flags that control deps are evil, as described in that same thread. (If you're not subscribed to gentoo-dev, find some archive website and search for a thread with subject 'Remove no<insert feature here> USE-flags from the tree'). If bug #61732 was implemented, we could do this, but that won't be anytime soon.
*** Bug 85476 has been marked as a duplicate of this bug. ***
