[gentoo-user] Re: Finer grained kde*-meta packages
Dirk Heinrichs [EMAIL PROTECTED] wrote: I completely agree with Alexander about this. Meta (not only the kde ones) packages should definitely have USE flags. http://bugs.gentoo.org/show_bug.cgi?id=182106 Let's see how fast Jakub is to close that bug... In that bug, I'm only talking about KDE stuff, as that's the by far largest sum of meta-packages. Alexander Skwar -- [EMAIL PROTECTED] mailing list
[gentoo-user] Re: Finer grained kde*-meta packages
Boyd Stephen Smith Jr. [EMAIL PROTECTED] wrote: On Friday 15 June 2007, Alexander Skwar [EMAIL PROTECTED] Yep. You get kde-meta or individual kde packages or you get your own ebuild that depends on a number of KDE packages. The Gentoo developers do quite a bit of work just to give us kde-meta. Be glad they don't stick you with the monolithic ebuilds. I am glad and thankful that they provide the meta stuff. But I think, that the meta packages can be enhanced. Nah. IMO that's the wrong way around. IMO the correct way would be to enhance the kde*-meta packages so, that they support USE flags, which allow the user to select what's to be installed. I suppose that's a good idea in the future. Perhaps you should file an enhancement bug. Done. http://bugs.gentoo.org/show_bug.cgi?id=182106 That said, I would prefer kde-meta install all the packages that are part of KDE's upstream packaging by default. Fine. Me not. That's the whole point of having choices :) Uhm - reading again what you wrote: Me too!. By default, all the upstream packages should be installed. Yes. By default. But please give me the choice. Eg. a ppp flag to select that ppp related stuff is to be installed. Or filesharing to disable filesharing related stuf Do you suggest a global flag? I don't think so. I'd rather think, that those flags should be local ones to the package. If so, what packages do you recommend this flags modify the behavior of? Depends :) This post was not so much about the ppp/kppp issue anymore. I wanted to see, if other people would think that a finer grained control would be a good idea. If not, shouldn't it have a less ambiguous name? The ppp flag is already known to portage. --($:~/tmp)-- euses -i ppp net-dialup/capi4k-utils:pppd - Installs pppdcapiplugin modules But maybe dialup might be good. But that's details. I mean, what's the advantage of the kde*-meta packages over the kde package, when the kde*-meta require just as much junk, as the kde package does? Hm, really, what's the use of the kde*-meta package anyway? The kde-meta package is meant to replace the kde package. The is no advantage (and without a workable confcache, at least one disadvantage) to running split ebuilds. The advantage of split ebilds is that you have the choice to install only the kde applications you want, by using the individual ebaulds, without dragging in all of kde (which is what old style kde packages pulled in as a dependency.) But with using the kde*-meta package, this advantage doesn't exist. Suppose you've got the following use case: Install all of KDE, but leave out PPP stuff. How would you solve that? cd /usr/portage emerge `ls -1 kde-*/* | grep -v ppp` I think not... (Yes, I know that this does not work.) If it were possible to exclude certain applications or, maybe even better, certain functions, then this use case could easily be solved. But maybe it's really just something peculiar about KDE, as KDE consists of about 300 packages. Because of that gigantic number, I could imagine that people might want to install everything, but XYZ. At least that's my reasoning. Are the monolithic ebuilds still available? Yes. Eg. kdemultimedia-3.5.7.ebuild They need to be purged from the tree ASAP. Have phun with bugzilla :) Or where should something like this actually be brought up? - Your signature is delimited in a wrong way. Please could you add the proper delimiter (ie. -- \n)? This would allow certain user agents (like Knode and many others) to strip away the .sig when quoting. Alexander Skwar -- [EMAIL PROTECTED] mailing list
[gentoo-user] Re: Finer grained kde*-meta packages (was: Make portage assume, that a package is installed)
Alan McKinnon [EMAIL PROTECTED] wrote: On Friday 15 June 2007, Alexander Skwar wrote: I mean, what's the advantage of the kde*-meta packages over the kde package, when the kde*-meta require just as much junk, as the kde package does? Hm, really, what's the use of the kde*-meta package anyway? The -meta packages are a good idea. Absolutely! With the old style kde or kdepim etc packages, you got everything whether you liked it or not. Well, that's what you get now as well... Eg. I don't want kppp, but I get anyway, whether I like it or not. At least sort of. Putting a USE flag on such an ebuild to build all of kdepim except kppp would be ... tricky at best. True. The -meta packages split everything in kde up on an app level, but there is the disadvantage that you now have 300 ebuilds to choose from and get to list *all* the ones you want. Exactly. Perhaps the best route (maybe a good feature request?) is to put USE flags in the -meta ebuilds. That's what I'd like to get as a result of http://bugs.gentoo.org/show_bug.cgi?id=182106 Then you get the full configurability of what -meta gives, plus an easy way to omit stuff without having to list 100 desired packages Exactly. Best regards, Alexander Skwar -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] Re: Finer grained kde*-meta packages (was: Make portage assume, that a package is installed)
On Friday 15 June 2007, Alexander Skwar wrote: Perhaps the best route (maybe a good feature request?) is to put USE flags in the -meta ebuilds. That's what I'd like to get as a result of http://bugs.gentoo.org/show_bug.cgi?id=182106 I see we're thinking along the same lines. Now, how fine grained do you want to take this? I can see that a ppp flag local to kde is good (people will either use dialup often, or not need it at all). artwork? some of those downloads are very big, so some user might want a way to install only the minimal artwork and never the rest. I'd like a way to not build the various admin gui tools - hell will freeze over long before I ever use anything other than vi to edit a crontab. And so on and so on. Or are you just looking for agreement and a mechanism to put use flags into split ebuilds and let the devs decide which ones are worth persuing? alan -- Optimists say the glass is half full, Pessimists say the glass is half empty, Developers say wtf is the glass twice as big as it needs to be? Alan McKinnon alan at linuxholdings dot co dot za +27 82, double three seven, one nine three five -- [EMAIL PROTECTED] mailing list
[gentoo-user] Re: Finer grained kde*-meta packages
Alan McKinnon [EMAIL PROTECTED] wrote: On Friday 15 June 2007, Alexander Skwar wrote: Perhaps the best route (maybe a good feature request?) is to put USE flags in the -meta ebuilds. That's what I'd like to get as a result of http://bugs.gentoo.org/show_bug.cgi?id=182106 I see we're thinking along the same lines. Now, how fine grained do you want to take this? Not *TOO* fine grained, as this would/might be too confusing. I don't think it might be a good idea to now introduce like 300 flags, so that each and every package can be dis-/enabled. I can see that a ppp flag local to kde is good (people will either use dialup often, or not need it at all). Yep. artwork? some of those downloads are very big, so some user might want a way to install only the minimal artwork and never the rest. Maybe. I'd like a way to not build the various admin gui tools - hell will freeze over long before I ever use anything other than vi to edit a crontab. In this case, a admin-tools USE flag might be good for you. And it could be shared with Gnome as well. And so on and so on. Or are you just looking for agreement Yep :) and a mechanism to put use flags into split ebuilds and let the devs decide which ones are worth persuing? With split ebuilds you mean for example the ebuild for kppp? Or are you talking about the kde*-meta ebuilds? My focus is on the meta ebuilds. There I'd like to be able to control to a finer degree, what's to be installed and what's not to be installed. Alexander Skwar -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] Re: Finer grained kde*-meta packages
On Friday 15 June 2007, Alexander Skwar wrote: and a mechanism to put use flags into split ebuilds and let the devs decide which ones are worth persuing? With split ebuilds you mean for example the ebuild for kppp? Or are you talking about the kde*-meta ebuilds? Sorry for not being clearer. I meant USE flags in the -meta ebuilds, to disable undesired apps like kppp. Sort of like: DEPEND= kde-base/this-app !nokppp? ( kde-base/kppp ) kde-base/that-app I use a no* flag as the default should be to install everything except the stuff the user doesn't want. Expecting user to enable a bunch of flags to get the equivalent of an upstream ebuild is a bit much :-) My focus is on the meta ebuilds. There I'd like to be able to control to a finer degree, what's to be installed and what's not to be installed. So, we're on the same wavelength. Think I'll pop over to bgo and add my voice to the comments... alan -- Optimists say the glass is half full, Pessimists say the glass is half empty, Developers say wtf is the glass twice as big as it needs to be? Alan McKinnon alan at linuxholdings dot co dot za +27 82, double three seven, one nine three five -- [EMAIL PROTECTED] mailing list
[gentoo-user] Re: Finer grained kde*-meta packages
Alan McKinnon [EMAIL PROTECTED] wrote: On Friday 15 June 2007, Alexander Skwar wrote: Sorry for not being clearer. I meant USE flags in the -meta ebuilds, to disable undesired apps like kppp. Sort of like: DEPEND= kde-base/this-app !nokppp? ( kde-base/kppp ) kde-base/that-app I use a no* flag as the default should be to install everything except the stuff the user doesn't want. Good idea! Maybe not nokppp, but better no-$function, ie. no-ppp, so that functions can be excluded, which might exclude more than just 1 package. Eg. no-admin-tools to include KDE GUI admin stuff. Expecting user to enable a bunch of flags to get the equivalent of an upstream ebuild is a bit much :-) You're right. My focus is on the meta ebuilds. There I'd like to be able to control to a finer degree, what's to be installed and what's not to be installed. So, we're on the same wavelength. Think I'll pop over to bgo and add my voice to the comments... Thx. Alexander Skwar -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] Re: Finer grained kde*-meta packages
On Friday 15 June 2007, Alexander Skwar [EMAIL PROTECTED] wrote about '[gentoo-user] Re: Finer grained kde*-meta packages': Boyd Stephen Smith Jr. [EMAIL PROTECTED] wrote: On Friday 15 June 2007, Alexander Skwar [EMAIL PROTECTED] The ppp flag is already known to portage. --($:~/tmp)-- euses -i ppp net-dialup/capi4k-utils:pppd - Installs pppdcapiplugin modules That's pppd, not ppp But maybe dialup might be good. But that's details. Yes, much easier to understand. I mean, what's the advantage of the kde*-meta packages over the kde package, when the kde*-meta require just as much junk, as the kde package does? Hm, really, what's the use of the kde*-meta package anyway? The kde-meta package is meant to replace the kde package. The is no advantage (and without a workable confcache, at least one disadvantage) to running split ebuilds. The advantage of split ebilds is that you have the choice to install only the kde applications you want, by using the individual ebaulds, without dragging in all of kde (which is what old style kde packages pulled in as a dependency.) But with using the kde*-meta package, this advantage doesn't exist. Right, because kde*-meta is supposed to replace, and act as much as possible like the monolithic kde* package. If you don't want all of kdenetwork you don't install kdenetwork-meta, you install individual applications from kdenetwork. Of course, any USE flags available on the old monolithic packages, as well as any use configure options from upstream, should be exposed. Are the monolithic ebuilds still available? Yes. Eg. kdemultimedia-3.5.7.ebuild They need to be purged from the tree ASAP. Have phun with bugzilla :) Or where should something like this actually be brought up? Probably the developer list, I'm sure someone from the kde herd would hear you there. - Your signature is delimited in a wrong way. Odd, I must have accidentally cut one of the -s. Kmail properly uses -- \n as this message and my first in the thread can attest. It does let you edit you signature and the separator, and I must have mistakenly taken advantage of that. -- Boyd Stephen Smith Jr. ,= ,-_-. =. [EMAIL PROTECTED] ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.org/ \_/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Finer grained kde*-meta packages
On Friday 15 June 2007, Alexander Skwar [EMAIL PROTECTED] wrote about '[gentoo-user] Re: Finer grained kde*-meta packages': Suppose you've got the following use case: Install all of KDE, but leave out PPP stuff. How would you solve that? Intall all the kde*-meta packages except kde-meta (I want to customize my kde install) and kdenetwork-meta (Specifically, I want to adjust network [ppp] support). Install any packages I need but don't have yet via the split ebuilds. Just because kde-meta doesn't satisfy your needs you don't have to forgo using the -meta ebuilds entirely. In your case it will probably be 30 packages you need to install, not 300. -- Boyd Stephen Smith Jr. ,= ,-_-. =. [EMAIL PROTECTED] ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.org/ \_/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Finer grained kde*-meta packages
On 6/16/07, Boyd Stephen Smith Jr. [EMAIL PROTECTED] wrote:
On Friday 15 June 2007, Alexander Skwar [EMAIL PROTECTED] wrote
about '[gentoo-user] Re: Finer grained kde*-meta packages':
Suppose you've got the following use case: Install all of
KDE, but leave out PPP stuff.
How would you solve that?
Intall all the kde*-meta packages except kde-meta (I want to customize my
kde install) and kdenetwork-meta (Specifically, I want to adjust network
[ppp] support). Install any packages I need but don't have yet via the
split ebuilds.
I have an idea, but it would probably involve a change in portage
itself instead of a mere ebuild useflag change.
That idea is basically optional dep if installable
ie:
kdenetwork-meta:
(opdep =kde-base/kppp)
which by default would pull kppp if there was an unmasked copy in the
tree and to skip pulling it, you would just p-mask it
Reason of course being that I for one, a list of 30 useflags all
titled with no on the front of them would be a little daunting
( Im not saying it /should/ be done like this, but I just try cover
other areas / techniques that haven't been investigated yet in the off
chance somebody else will see a great idea offshoot from it )
--
Kent
ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x|
print enNOSPicAMreil [EMAIL PROTECTED][(2*x)..(2*x+1)]}'
--
[EMAIL PROTECTED] mailing list
