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
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
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