[gentoo-user] Make portage assume, that a package is installed

[gentoo-user] Make portage assume, that a package is installed

[Alexander Skwar]

Good morning!

On my system, I don't use a modem and don't intend to ever
do so. Because of this, I did not install net-dialup/ppp.
But I'd now like to install kde-base/kde-meta, which will
pull in kde-base/kdenetwork-meta, which will pull in kde-base/kppp
and this will finally pull in net-dialup/ppp.

Can I now make it somehow so, that I am able to install kdenetwork-meta,
but NOT install kppp & ppp?

In the documentation at <http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=5>
and in man portage at <http://gentoo-wiki.com/MAN_Portage>, I read,
that I might be able to use the package.provided file. But according
to the man page, it is located in the profile directory (/etc/make.profile).
I'd rather NOT fiddle with files in such a directory.

So I tried to create the file in /etc/portage. Contents:

--($:~)-- cat /etc/portage/package.provided
kde-base/kppp-3.5.7
net-dialup/ppp-2.4.4-r8

But when I run emerge, I get the following output:

[nomerge      ] kde-base/kde-meta-3.5.7  USE="-accessibility nls" 
[ebuild  N    ]  kde-base/kdenetwork-meta-3.5.7  USE="wifi" 0 kB 
[ebuild  N    ]   kde-base/kppp-3.5.7  USE="-arts -debug kdeenablefinal kdehiddenvisibility xinerama" 0 kB 
[ebuild  N    ]    net-dialup/ppp-2.4.4-r8  USE="-activefilter -atm -dhcp -eap-tls gtk -ipv6 -mppe-mppc pam -radius" 0 kB 
[nomerge      ] net-im/ekiga-2.0.9  USE="-avahi dbus -debug doc gnome sdl" 

Ie. ppp would be installed.

Obviously, I'm doing something wrong.

How do I do it right?

Thanks,

Alexander Skwar

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Make portage assume, that a package is installed

[Justin Findlay]

On AD 2007 June 15 Friday 08:55:40 AM +0200, Alexander Skwar wrote:
> On my system, I don't use a modem and don't intend to ever
> do so. Because of this, I did not install net-dialup/ppp.
> But I'd now like to install kde-base/kde-meta, which will
> pull in kde-base/kdenetwork-meta, which will pull in kde-base/kppp
> and this will finally pull in net-dialup/ppp.

When I encountered this one (there really should be a ppp flag for
the kdenetwork ebuild), I did this:

# vi $(equery which kdenetwork)

Find the line in RDEPEND that says net-dialup/ppp and delete it.

# ebuild $(equery which kdenetwork) digest
# emerge -uDN world

It seems like a hack, and it is, but it worked for me.


Justin
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: Make portage assume, that a package is installed

[Alexander Skwar]

Justin Findlay <justin@jfindlay.us> wrote:

> On AD 2007 June 15 Friday 08:55:40 AM +0200, Alexander Skwar wrote:
>> On my system, I don't use a modem and don't intend to ever
>> do so. Because of this, I did not install net-dialup/ppp.
>> But I'd now like to install kde-base/kde-meta, which will
>> pull in kde-base/kdenetwork-meta, which will pull in kde-base/kppp
>> and this will finally pull in net-dialup/ppp.
> 
> When I encountered this one (there really should be a ppp flag for

Yep.

> the kdenetwork ebuild), I did this:
> 
> # vi $(equery which kdenetwork)

Thanks. But I also do not want to edit the ebuild :) BTW:
It would be better to first copy it to a local overlay, I'd
think.

Alexander Skwar

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Make portage assume, that a package is installed

[Peter Alfredsen]

On Friday 15 June 2007, Alexander Skwar wrote:
> Good morning!
>
> On my system, I don't use a modem and don't intend to ever
> do so. Because of this, I did not install net-dialup/ppp.
> But I'd now like to install kde-base/kde-meta, which will
> pull in kde-base/kdenetwork-meta, which will pull in kde-base/kppp
> and this will finally pull in net-dialup/ppp.
>
> Can I now make it somehow so, that I am able to install kdenetwork-meta,
> but NOT install kppp & ppp?
>
> In the documentation at
> <http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=5> and
> in man portage at <http://gentoo-wiki.com/MAN_Portage>, I read, that I
> might be able to use the package.provided file. But according to the man
> page, it is located in the profile directory (/etc/make.profile). I'd
> rather NOT fiddle with files in such a directory.
>
> So I tried to create the file in /etc/portage. Contents:
>
> --($:~)-- cat /etc/portage/package.provided
> kde-base/kppp-3.5.7
> net-dialup/ppp-2.4.4-r8
[...]
> Obviously, I'm doing something wrong.
>
> How do I do it right?

See:
http://marc.info/?l=gentoo-user&m=114173922424811&w=2
Basically:
mkdir /etc/portage/profile
cp /etc/portage/package.provided /etc/portage/profile/package.provided

Try it.

You might want to leave out the version numbers from kppp and ppp (Think of 
what happens when kppp 3.5.8 comes out or when ppp-2.4.4-r9 comes out).

-- 
/PA
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Make portage assume, that a package is installed

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 2025 bytes --]

On Friday 15 June 2007, Alexander Skwar <listen@alexander.skwar.name> wrote 
about '[gentoo-user]  Make portage assume, that a package is installed':
> Good morning!
>
> On my system, I did not install net-dialup/ppp.
> But I'd now like to install kde-base/kde-meta, which will
> pull in kde-base/kdenetwork-meta, which will pull in kde-base/kppp
> and this will finally pull in net-dialup/ppp.
>
> Can I now make it somehow so, that I am able to install kdenetwork-meta,
> but NOT install kppp & ppp?
>
> So I tried to create the file in /etc/portage. Contents:
>
> --($:~)-- cat /etc/portage/package.provided
> kde-base/kppp-3.5.7
> net-dialup/ppp-2.4.4-r8
>
> Obviously, I'm doing something wrong.
>
> How do I do it right?

As Peter Alfredsen mentioned, overrides for your profile should go 
in /etc/portage/profile instead of /etc/portage.

However, I suggest that a cleaner method would be to not install kde-meta 
or kdenetwork-meta at all but instead just install the KDE applications 
that you require.

For example:
$ grep -i kde /var/db/pkg/world
dev-util/kdesvn
kde-base/akregator
kde-base/kalzium
kde-base/kaudiocreator
kde-base/kcharselect
kde-base/kdeartwork-kscreensaver
kde-base/kdeartwork-kwin-styles
kde-base/kdeartwork-styles
kde-base/kdebase-startkde
kde-base/kdm
kde-base/kget
kde-base/kgpg
kde-base/kicker-applets
kde-base/klipper
kde-base/kmahjongg
kde-base/kmail
kde-base/kmenuedit
kde-base/kmix
kde-base/kompare
kde-base/konq-plugins
kde-base/konqueror-akregator
kde-base/konsole
kde-base/kontact
kde-base/korganizer
kde-base/kpager
kde-base/kpdf
kde-base/kscreensaver
kde-base/kstars
kde-base/ksysguard
kde-base/kwalletmanager
kde-base/kwin
kde-base/superkaramba
kde-misc/kdiff3
kde-misc/filelight

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-user] Re: Make portage assume, that a package is installed

[Alexander Skwar]

Peter Alfredsen <peter.alfredsen@gmail.com> wrote:
> On Friday 15 June 2007, Alexander Skwar wrote:

>> So I tried to create the file in /etc/portage. Contents:
>>
>> --($:~)-- cat /etc/portage/package.provided
>> kde-base/kppp-3.5.7
>> net-dialup/ppp-2.4.4-r8
> [...]
>> Obviously, I'm doing something wrong.
>>
>> How do I do it right?
> 
> See:
> http://marc.info/?l=gentoo-user&m=114173922424811&w=2
> Basically:
> mkdir /etc/portage/profile
> cp /etc/portage/package.provided /etc/portage/profile/package.provided
> 
> Try it.

Works. Difference to what I did: You suggested to have the
file in the /etc/portage/profile directory. I had it directly
in /etc/portage. Mistake I made: I overlooked the following
from the man page:

,----[ man portage ]
| /etc/portage/profile/
|     site-specific overrides of /etc/make.profile/ 
`----

> You might want to leave out the version numbers from kppp and ppp (Think
> of what happens when kppp 3.5.8 comes out or when ppp-2.4.4-r9 comes out).

Well, but read the man page for portage:

,----[ man portage, package.provided section ]
|                      Format:
|                      - comments begin with #
|                      - one DEPEND atom per line
|                      - relational operators are not allowed
|                      - must include a version
`----

Also see what happens, when you leave out the version number:

--($:~)-- Gestoppt sudo emerge -DuvatN world
Invalid package name in package.provided: net-dialup/ppp
Invalid package name in package.provided: kde-base/kppp
See portage(5) for correct package.provided usage.

--($:~)-- cat /etc/portage/profile/package.provided 
kde-base/kppp
net-dialup/ppp

OTOH: I agree with you. It would/might be better, if the
version number would not need to be included.

Cheers and thanks for the help,

Alexander Skwar

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: Make portage assume, that a package is installed

[Alexander Skwar]

Justin Findlay <justin@jfindlay.us> wrote:

> When I encountered this one (there really should be a ppp flag for
> the kdenetwork ebuild), I did this:

I just filed a bug reg. this. It includes a "fixed" ebuild.

See Bug #182099 at <http://bugs.gentoo.org/show_bug.cgi?id=182099>.

Alexander Skwar

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Finer grained kde*-meta packages (was: Make portage assume, that a package is installed)

[Alexander Skwar]

Boyd Stephen Smith Jr. <bss03@volumehost.net> wrote:

> However, I suggest that a cleaner method would be to not install kde-meta
> or kdenetwork-meta at all but instead just install the KDE applications
> that you require.

Actually, I disagree.

This would (obviously *g*) mean, that kde-meta cannot be installed
(just as you say). This means, that a whole "shit load" of packages
would need to be manually installed. And all that, just because you
don't want one or two packages?

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.

Eg. a "ppp" flag to select that ppp related stuff is to be installed.
Or "filesharing" to disable filesharing related stuf (kdenetwork-filesharing
and kpf - or whatever). Or if you don't use feeds, why install
dcoprss and knewsticker?

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?

Alexander Skwar

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Finer grained kde*-meta packages

[Dirk Heinrichs]

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

Am Freitag, 15. Juni 2007 schrieb ext Alexander Skwar:

> This would (obviously *g*) mean, that kde-meta cannot be installed
> (just as you say). This means, that a whole "shit load" of packages
> would need to be manually installed. And all that, just because you
> don't want one or two packages?
>
> 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 completely agree with Alexander about this. Meta (not only the kde ones) 
packages should definitely have USE flags.

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

Allow for selective update (kmail-3.5.6 -> kmail-3.5.6-r1) instead of 
updating kdenetwork.

Bye...

	Dirk
-- 
Dirk Heinrichs          | Tel:  +49 (0)162 234 3408
Configuration Manager   | Fax:  +49 (0)211 47068 111
Capgemini Deutschland   | Mail: dirk.heinrichs@capgemini.com
Wanheimerstraße 68      | Web:  http://www.capgemini.com
D-40468 Düsseldorf      | ICQ#: 110037733
GPG Public Key C2E467BB | Keyserver: www.keyserver.net

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Finer grained kde*-meta packages (was: Make portage assume, that a package is installed)

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 2708 bytes --]

On Friday 15 June 2007, Alexander Skwar <listen@alexander.skwar.name> wrote 
about '[gentoo-user]  Finer grained kde*-meta packages (was: Make portage 
assume, that a package is installed)':
> Boyd Stephen Smith Jr. <bss03@volumehost.net> wrote:
> > However, I suggest that a cleaner method would be to not install
> > kde-meta or kdenetwork-meta at all but instead just install the KDE
> > applications that you require.
>
> Actually, I disagree.
>
> This would (obviously *g*) mean, that kde-meta cannot be installed
> (just as you say).

Yes, because the upstream kde includes, in particular, kppp.

> This means, that a whole "shit load" of packages 
> would need to be manually installed. And all that, just because you
> don't want one or two packages?

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.

> 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.  That said, I would prefer kde-meta install all the 
packages that are part of KDE's upstream packaging by default.

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

If so, what packages do you recommend this flags modify the behavior of?

If not, shouldn't it have a less ambiguous name?

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

Are the monolithic ebuilds still available?  They need to be purged from 
the tree ASAP.

- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-user] Re: Finer grained kde*-meta packages

[Alexander Skwar]

Dirk Heinrichs <dirk.heinrichs.ext@nsn.com> 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

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Finer grained kde*-meta packages (was: Make portage assume, that a package is installed)

[Alan McKinnon]

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. With the old style kde or kdepim etc 
packages, you got everything whether you liked it or not. Putting a USE 
flag on such an ebuild to build all of kdepim except kppp would be ... 
tricky at best.

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.

Perhaps the best route (maybe a good feature request?) is to put USE 
flags in the -meta ebuilds. Then you get the full configurability of 
what -meta gives, plus an easy way to omit stuff without having to list 
>100 desired packages

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
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: Finer grained kde*-meta packages

[Alexander Skwar]

Boyd Stephen Smith Jr. <bss03@volumehost.net> wrote:
> On Friday 15 June 2007, Alexander Skwar <listen@alexander.skwar.name>

> 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

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: Finer grained kde*-meta packages (was: Make portage assume, that a package is installed)

[Alexander Skwar]

Alan McKinnon <alan@linuxholdings.co.za> 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

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Finer grained kde*-meta packages (was: Make portage assume, that a package is installed)

[Peter Ruskin]

On Friday 15 June 2007, Boyd Stephen Smith Jr. wrote:
> Are the monolithic ebuilds still available?  They need to be
> purged from the tree ASAP.

Why?  So that all Gentoo users are like you?  I think not.  I used 
the kde-meta-* packages for a while - they seemed like a good idea; 
but I now use the monolithic packages again, as they make life much 
simpler for me.  With big hard discs cheap and with ADSL 
connection, the advantages of the meta packages are diminished.

-- 
Peter
========================================================================
Gentoo Linux: Portage 2.1.2.9		kernel-2.6.21-gentoo-r2
AMD Athlon(tm) 64 X2 Dual Core Processor 4400+	gcc(GCC): 4.1.2
KDE: 3.5.7					Qt: 3.3.8
========================================================================
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: Finer grained kde*-meta packages (was: Make portage assume, that a package is installed)

[Alan McKinnon]

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
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: Finer grained kde*-meta packages

[Alexander Skwar]

Alan McKinnon <alan@linuxholdings.co.za> 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

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: Finer grained kde*-meta packages

[Alan McKinnon]

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
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: Finer grained kde*-meta packages

[Alexander Skwar]

Alan McKinnon <alan@linuxholdings.co.za> 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

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Finer grained kde*-meta packages

[Dale]

Peter Ruskin wrote:
>
> With big hard discs cheap and with ADSL 
> connection, the advantages of the meta packages are diminished.
>
>   

If I understand your meaning correctly, not everyone can get broadband. 
I'm on dial-up and it is all that is available here where I live.  DSL
may be here soon but not yet.

Dale

:-)  :-)
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: Finer grained kde*-meta packages

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 2567 bytes --]

On Friday 15 June 2007, Alexander Skwar <listen@alexander.skwar.name> wrote 
about '[gentoo-user]  Re: Finer grained kde*-meta packages':
> Boyd Stephen Smith Jr. <bss03@volumehost.net> wrote:
> > On Friday 15 June 2007, Alexander Skwar <listen@alexander.skwar.name>
> 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.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Re: Finer grained kde*-meta packages

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 940 bytes --]

On Friday 15 June 2007, Alexander Skwar <listen@alexander.skwar.name> 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.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Re: Finer grained kde*-meta packages

[Kent Fredric]

On 6/16/07, Boyd Stephen Smith Jr. <bss03@volumehost.net> wrote:
> On Friday 15 June 2007, Alexander Skwar <listen@alexander.skwar.name> 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 kdrtf@gma.com"[(2*x)..(2*x+1)]}'
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: Re: Finer grained kde*-meta packages

[Alexander Skwar]

· Boyd Stephen Smith Jr. <bss03@volumehost.net>:

> On Friday 15 June 2007, Alexander Skwar <listen@alexander.skwar.name> wrote 
> about '[gentoo-user]  Re: Finer grained kde*-meta packages':
>> Boyd Stephen Smith Jr. <bss03@volumehost.net> wrote:
>> > On Friday 15 June 2007, Alexander Skwar <listen@alexander.skwar.name>

>> But maybe "dialup" might be good. But that's details.
> 
> Yes, much easier to understand.

Well, fine. Details, 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.
> 
> 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.

Well, but as kdenetwork-meta is a dependency of kde-meta, this
"solution" means, that about 300 packages should be manually
listed, just because one package is not wanted. Because of that,
this is not really a solution - at least not a good one.

Alexander Skwar
-- 
Judges, as a class, display, in the matter of arranging alimony, that
reckless generosity which is found only in men who are giving away
someone else's cash.
                -- P.G. Wodehouse, "Louder and Funnier"


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: Re: Finer grained kde*-meta packages

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 1750 bytes --]

On Saturday 16 June 2007, Alexander Skwar <listen@alexander.skwar.name> 
wrote about '[gentoo-user]  Re: Re: Finer grained kde*-meta packages':
> · Boyd Stephen Smith Jr. <bss03@volumehost.net>:
> > 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.
>
> Well, but as kdenetwork-meta is a dependency of kde-meta, this
> "solution" means, that about 300 packages should be manually
> listed, just because one package is not wanted.

No, because as I covered in my other reply, you can still use kdebase-meta, 
kdepim-meta, etc. to pull is all the packages from those parts of kde and 
only list individual applications from the parts you don't want everything 
from (in your case you should be able to use every kde<foo>-meta 'cept for 
kdenetwork-meta).  For your particular use case it's still < 30 packages, 
not 300.

Sure, maybe that's still too many.  Perhaps a "recommends"/"suggests" 
dependency type (all recommends would be post-dependencies) to allow a 
package to install even if all of the packages that satisfy one of it's 
recommend atoms are masked would be better, but you'll have to take that 
up with the developers responsible for specifying the EAPI levels.  
Careful how you phrase any suggestion though or you'll just get shouted 
down by "Gentoo isn't Debian" replies.

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Make portage assume, that a package is installed

[Jan Seeger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sorry for being late, but have you tried to add the offending packages
to package.provided and then emerging the meta packages? Not exactly
clean, but cleaner than editing the ebuild, and it works...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFGc9USMmLQdC6jvocRAuR1AKCg6iaXJQN0lsbx/NGNZQs5oZge5QCgm9YE
/tv2oDIgGf3X1zgxkmdCjbQ=
=Y+2y
-----END PGP SIGNATURE-----
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Finer grained kde*-meta packages

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

On Sat, 16 Jun 2007 06:08:52 -0500, Boyd Stephen Smith Jr. wrote:

> > Well, but as kdenetwork-meta is a dependency of kde-meta, this
> > "solution" means, that about 300 packages should be manually
> > listed, just because one package is not wanted.  
> 
> No, because as I covered in my other reply, you can still use
> kdebase-meta, kdepim-meta, etc. to pull is all the packages from those
> parts of kde and only list individual applications from the parts you
> don't want everything from (in your case you should be able to use
> every kde<foo>-meta 'cept for kdenetwork-meta).  For your particular
> use case it's still < 30 packages, not 300.

It's less than that, because the KDE split ebuilds contain a number of
packages that should never need to be installed directly. One already
mentioned in this thread is dcoprss, which is pulled in by packages that
need it.

I'm not sure USE flags for the meta packages are a good idea, they could
add a lot of confusion. The meta packages are supposed to install
everything, if you don't want that, don't use them.


-- 
Neil Bothwick

Ultimate memory manager; Windows, it manages to use it all..

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Finer grained kde*-meta packages (was: Make portage assume, that a package is installed)

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 545 bytes --]

On Fri, 15 Jun 2007 05:10:00 -0500, Boyd Stephen Smith Jr. wrote:

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

What about the need to recompile only one part of KDE when a security fix
is released? If a fix is released for kppp, you only have to rebuild that
(or not in the case of Alexander :) rather than the whole of kdenetwork.


-- 
Neil Bothwick

Unsupported service (adj): Broken (see Demon)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Finer grained kde*-meta packages

[Alan McKinnon]

On Monday 18 June 2007, Neil Bothwick wrote:

> I'm not sure USE flags for the meta packages are a good idea, they
> could add a lot of confusion. The meta packages are supposed to
> install everything, if you don't want that, don't use them.

I think what Alexander is on about is USE flags only for features that 
require other sub-systems outside KDE to be installed as well. Like ppp 
for example, or printers and scanners for another. Obviously a policy 
run by a human is what it will take otherwise it gets out of hand very 
very quickly.

'emerge *-meta' is fine if one wants everything, or 'emerge kopete kmail 
konqueror' if you just want a few bits like me, but there's this large 
no-man's land in the middle where it is just unweildy. No fault of 
Gentoo, it's all KDEs fault for having 300+ distinct apps/code 
bodies :-)

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
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Finer grained kde*-meta packages

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

Hello Alan McKinnon,

> 'emerge *-meta' is fine if one wants everything, or 'emerge kopete
> kmail konqueror' if you just want a few bits like me, but there's this
> large no-man's land in the middle where it is just unweildy. No fault
> of Gentoo, it's all KDEs fault for having 300+ distinct apps/code 
> bodies :-)

But you don't need all of them in world, many are only installed as
dependencies of other packages. I have most of KDE installed here, yet
only 67 kde-base packages in world. You could reduce that sill further
by using more than the two meta packages I currently have. 


-- 
Neil Bothwick

Q: Why do PCs - even modern ones - have reset buttons on the front?
A: Because they come with Microsoft operating systems.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Finer grained kde*-meta packages

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

On Monday 18 June 2007 14:36:05 Neil Bothwick wrote:
> I have most of KDE installed here, yet
> only 67 kde-base packages in world.

I run fairly light, I have about half that many:

$ grep -c ^kde /var/db/pkg/world
31

I do have a number of KDE applications installed from other parts of the tree 
though, like kmplayer, kaffeine, ktorrent, etc.

> You could reduce that sill further 
> by using more than the two meta packages I currently have.

Again, since I prefer to just install the apps I want, I only pulled in 1 meta 
package.

$ grep ^kde /var/db/pkg/world | grep -e '-meta$'
kde-base/kdeartwork-meta

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Finer grained kde*-meta packages

[Peter Ruskin]

On Monday 18 June 2007, Boyd Stephen Smith Jr. wrote:
> On Monday 18 June 2007 14:36:05 Neil Bothwick wrote:
> > I have most of KDE installed here, yet
> > only 67 kde-base packages in world.
>
> I run fairly light, I have about half that many:
>
> $ grep -c ^kde /var/db/pkg/world
> 31

I think your system may need updating - the world file has lived 
in /var/lib/portage for some time now.

-- 
Peter
========================================================================
Gentoo Linux: Portage 2.1.3_rc3		kernel-2.6.21-gentoo-r2
AMD Athlon(tm) 64 X2 Dual Core Processor 4400+	gcc(GCC): 4.1.2
KDE: 3.5.7					Qt: 3.3.8
========================================================================
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Finer grained kde*-meta packages

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

On Monday 18 June 2007 16:36:38 Peter Ruskin wrote:
> On Monday 18 June 2007, Boyd Stephen Smith Jr. wrote:
> > /var/db/pkg/world
>
> I think your system may need updating - the world file has lived
> in /var/lib/portage for some time now.

Paludis prefers it @ /var/db/pkg/world.  I have both on my system; one is just 
a symlink to the other.

My system was fully updated (~amd64) around 8a this morning, right before I 
left for work.

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Finer grained kde*-meta packages

[Alex Schuster]

On 2007-06-15, Dale wrote:

> Peter Ruskin wrote:
> > With big hard discs cheap and with ADSL
> > connection, the advantages of the meta packages are diminished.
>
> If I understand your meaning correctly, not everyone can get broadband.
> I'm on dial-up and it is all that is available here where I live.  DSL
> may be here soon but not yet.

How true, how true.

	Wonko