FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 11-27-2009, 08:07 PM
Jörg Schaible
 
Default FIXED: KDE3 removal

Alan McKinnon wrote:

> On Thursday 26 November 2009 19:34:34 James wrote:
>> kde-4.3.1 went smooth, except
>> for I have to manually removed all the kde-3.5 packages.
>> It had kde-meta-3.5.10. Is there some syntax or a better
>> method to insure all the kde-3.5.x packages are removed,
>> without a manual sweep?
>>
>
> grep kde /var/lib/portage/world
> and eyeball the output. There should only be -meta packages, and
> individual packages for which you have NOT installed the -meta package, in
> there. vi the world file and remove the stuff that shouldn't be there,
> then
>
> emerge -C <all-kde3.5-meta-packages-in-world> && emerge -a --depclean
>

as alternative simply append to all kde-base/* packages in world :4.3 and do
then a depclean ;-)

- Jörg
 
Old 11-27-2009, 09:15 PM
Alan McKinnon
 
Default FIXED: KDE3 removal

On Friday 27 November 2009 23:07:25 Jörg Schaible wrote:
> Alan McKinnon wrote:
> > On Thursday 26 November 2009 19:34:34 James wrote:
> >> kde-4.3.1 went smooth, except
> >> for I have to manually removed all the kde-3.5 packages.
> >> It had kde-meta-3.5.10. Is there some syntax or a better
> >> method to insure all the kde-3.5.x packages are removed,
> >> without a manual sweep?
> >
> > grep kde /var/lib/portage/world
> > and eyeball the output. There should only be -meta packages, and
> > individual packages for which you have NOT installed the -meta package,
> > in there. vi the world file and remove the stuff that shouldn't be there,
> > then
> >
> > emerge -C <all-kde3.5-meta-packages-in-world> && emerge -a --depclean
>
> as alternative simply append to all kde-base/* packages in world :4.3 and
> do then a depclean ;-)

Which promptly defeats the ENTIRE purpose of a world file and -meta packages.

If that's how you want to admin your box, can I recommend you switch to
sabayon instead?

--
alan dot mckinnon at gmail dot com
 
Old 11-27-2009, 11:01 PM
Mick
 
Default FIXED: KDE3 removal

On Friday 27 November 2009 15:53:41 Alan McKinnon wrote:
> On Friday 27 November 2009 17:27:30 James wrote:
> > Mick <michaelkintzios <at> gmail.com> writes:
> > > Hmm, I thought that kweather, kate and kfloppy were brought in by some
> > > meta or other. It seems that I'll have to install these on their own?
> >
> > Hello Mick,
> >
> > I'm just not certain any more exactly which packages belong to
> > which meta(kde) package. I think they are added and dropped
> > over the last few years, resulting in a dynamic grouping
> > or like those you mentioned, not being picked up by and of the
> > kde-meta packages.
>
> You fellows really need to read the full set of portage man pages. You
> sound like mechanics that don't know how spanners work.

I'm sure there's a spanner thrown somewhere in the works ...

> The contents of packages is determined by upstream (KDE), not by the gentoo
> devs. Gentoo devs merely split the monolithic tarballs up into whatever
> apps the KDE devs say is inside it
>
> To find out what is in a -meta package:
>
> cat $PORTDIR/kde-base/*-meta/*ebuild
>
> There isn't a special tool to do this, much as there isn't a tool to tell
> you what stuff DEPENDs on say apache. There is a general tool, it's
> equery depends -a
[snip ...]

> To find out what depends on kate, kweather and kfloppy, use the correct
> portage tool:
>
> alan@nazgul ~ $ equery depends -a kate
> * Searching for kate ...
> kde-base/kdesdk-meta-4.3.1 (>=kde-base/kate-4.3.1:4.3[kdeprefix=])
> kde-base/kdesdk-meta-4.3.3 (!kdeprefix ? >=kde-base/kate-4.3.3[-kdeprefix])
> (kdeprefix ?
> >=kde-base/kate-4.3.3:4.3[kdeprefix])

OK, but I am getting this much - slightly different to yours above:

# equery depends -a kate
[ Searching for packages depending on kate... ]
kde-base/kde-meta-4.3.1 (>=kde-base/kate-4.3.1:4.3[kdeprefix=])
kde-base/kdesdk-meta-4.3.1 (>=kde-base/kate-4.3.1:4.3[kdeprefix=])

Now, fair enough, I do not have kde-base/kde-meta installed, so nothing wants
to pull back in kate when I update world.

> > Let me know if you find a silver bullet (syntax) for discerning
> > what kde packages are grouped into which meta package or
> > not grouped at all..
>
> This is Unix. We use grep, sed and awk to find stuff.
>
> Much faster than just about anything else...

Right, but only if your regex-fu is good enough. Mine is rather pathetic ...
:-(

Grateful for all help received to pick up the right spanner. ;-)
--
Regards,
Mick
 
Old 11-28-2009, 10:59 AM
Jörg Schaible
 
Default FIXED: KDE3 removal

Alan McKinnon wrote:

> On Friday 27 November 2009 23:07:25 Jörg Schaible wrote:
>> Alan McKinnon wrote:
>> > On Thursday 26 November 2009 19:34:34 James wrote:
>> >> kde-4.3.1 went smooth, except
>> >> for I have to manually removed all the kde-3.5 packages.
>> >> It had kde-meta-3.5.10. Is there some syntax or a better
>> >> method to insure all the kde-3.5.x packages are removed,
>> >> without a manual sweep?
>> >
>> > grep kde /var/lib/portage/world
>> > and eyeball the output. There should only be -meta packages, and
>> > individual packages for which you have NOT installed the -meta package,
>> > in there. vi the world file and remove the stuff that shouldn't be
>> > there, then
>> >
>> > emerge -C <all-kde3.5-meta-packages-in-world> && emerge -a --depclean
>>
>> as alternative simply append to all kde-base/* packages in world :4.3 and
>> do then a depclean ;-)
>
> Which promptly defeats the ENTIRE purpose of a world file and -meta
> packages.

a) I've never used the meta packages, but selected my KDE apps on purpose
b) it's a lot easier this way to get rid of the KDE 3 stuff, however you
should get drop of the slot again after depclean has been finished

> If that's how you want to admin your box,

I am using long enough Gentoo that I remember very well the times when
portage destroyed the world file completely. And regenworld put *anything*
into world at that time. Therefore I know very well, what should be in this
file and what not. There's no magic.

> can I recommend you switch to
> sabayon instead?

ROFL! So, you mean, if users get too smart, Gentoo is no longer their
distribution? Don't be silly.

- Jörg
 
Old 11-28-2009, 12:07 PM
Alan McKinnon
 
Default FIXED: KDE3 removal

On Saturday 28 November 2009 13:59:38 Jörg Schaible wrote:
> Alan McKinnon wrote:
> > On Friday 27 November 2009 23:07:25 Jörg Schaible wrote:
> >> Alan McKinnon wrote:
> >> > On Thursday 26 November 2009 19:34:34 James wrote:
> >> >> kde-4.3.1 went smooth, except
> >> >> for I have to manually removed all the kde-3.5 packages.
> >> >> It had kde-meta-3.5.10. Is there some syntax or a better
> >> >> method to insure all the kde-3.5.x packages are removed,
> >> >> without a manual sweep?
> >> >
> >> > grep kde /var/lib/portage/world
> >> > and eyeball the output. There should only be -meta packages, and
> >> > individual packages for which you have NOT installed the -meta
> >> > package, in there. vi the world file and remove the stuff that
> >> > shouldn't be there, then
> >> >
> >> > emerge -C <all-kde3.5-meta-packages-in-world> && emerge -a --depclean
> >>
> >> as alternative simply append to all kde-base/* packages in world :4.3
> >> and do then a depclean ;-)
> >
> > Which promptly defeats the ENTIRE purpose of a world file and -meta
> > packages.
>
> a) I've never used the meta packages, but selected my KDE apps on purpose

You missed the part where the user clearly states earlier that he DOES use
-meta packages. With that in mind, any advice you give should be aligned to
the fact that he is a -meta user

> b) it's a lot easier this way to get rid of the KDE 3 stuff, however you
> should get drop of the slot again after depclean has been finished

How is it easier? You have to maintain the SLOTs in world yourself because the
instant you do that portage will not automagically offer to upgrade anymore
(upgrades within the same slot excepted). And --depclean will NOT adjust your
SLOTs in world when it's finished. I can't really make sense of your last
sentence but that is what you seem to imply


> > If that's how you want to admin your box,
>
> I am using long enough Gentoo that I remember very well the times when
> portage destroyed the world file completely.

That was long ago and no longer applicable. That bug in portage got fixed, so
a behaviour on your part to compensate for a bug that is not there is outdated
behaviour.

> And regenworld put *anything*
> into world at that time. Therefore I know very well, what should be in this
> file and what not. There's no magic.

Yes, the only things in world are packages you want that are not dependencies
of something else already in world. You are advising the user to put the
dependencies of -meta packages into world when the -meta package is already
there.

And that is plain silly

> > can I recommend you switch to
> > sabayon instead?
>
> ROFL! So, you mean, if users get too smart, Gentoo is no longer their
> distribution? Don't be silly.

Erm, you should read the whole thread and realise the bits you missed - the
bits that make your statements nonsensical



--
alan dot mckinnon at gmail dot com
 
Old 11-28-2009, 12:22 PM
Alan McKinnon
 
Default FIXED: KDE3 removal

On Saturday 28 November 2009 02:01:22 Mick wrote:
> > To find out what depends on kate, kweather and kfloppy, use the correct
> > portage tool:
> >
> > alan@nazgul ~ $ equery depends -a kate
> > * Searching for kate ...
> > kde-base/kdesdk-meta-4.3.1 (>=kde-base/kate-4.3.1:4.3[kdeprefix=])
> > kde-base/kdesdk-meta-4.3.3 (!kdeprefix ?
> > >=kde-base/kate-4.3.3[-kdeprefix]) (kdeprefix ?
> > >=kde-base/kate-4.3.3:4.3[kdeprefix])
>
> OK, but I am getting this much - slightly different to yours above:
>
> # equery depends -a kate
> [ Searching for packages depending on kate... ]
> kde-base/kde-meta-4.3.1 (>=kde-base/kate-4.3.1:4.3[kdeprefix=])
> kde-base/kdesdk-meta-4.3.1 (>=kde-base/kate-4.3.1:4.3[kdeprefix=])
>
> Now, fair enough, I do not have kde-base/kde-meta installed, so nothing
> wants to pull back in kate when I update world.
>

That's normal. The pre-defined sets in kde-testing overlay explicitly list
kate in the @kde set for that reason.

I suppose one could make several useful -meta packages DEPEND on kate, as many
users want kate and do not want the entire kdesdk package. But that causes the
same app to appear in more than one -meta package and the devs seem to want to
avoid that - there is a strict one-to-one mapping between what the -meta
packages install and what is shipped in the upstream tarballs by KDE


--
alan dot mckinnon at gmail dot com
 
Old 11-28-2009, 05:56 PM
Jörg Schaible
 
Default FIXED: KDE3 removal

Alan McKinnon wrote:

> On Saturday 28 November 2009 13:59:38 Jörg Schaible wrote:
>> Alan McKinnon wrote:
>> > On Friday 27 November 2009 23:07:25 Jörg Schaible wrote:
>> >> Alan McKinnon wrote:
>> >> > On Thursday 26 November 2009 19:34:34 James wrote:
>> >> >> kde-4.3.1 went smooth, except
>> >> >> for I have to manually removed all the kde-3.5 packages.
>> >> >> It had kde-meta-3.5.10. Is there some syntax or a better
>> >> >> method to insure all the kde-3.5.x packages are removed,
>> >> >> without a manual sweep?
>> >> >
>> >> > grep kde /var/lib/portage/world
>> >> > and eyeball the output. There should only be -meta packages, and
>> >> > individual packages for which you have NOT installed the -meta
>> >> > package, in there. vi the world file and remove the stuff that
>> >> > shouldn't be there, then
>> >> >
>> >> > emerge -C <all-kde3.5-meta-packages-in-world> && emerge -a
>> >> > --depclean
>> >>
>> >> as alternative simply append to all kde-base/* packages in world :4.3
>> >> and do then a depclean ;-)
>> >
>> > Which promptly defeats the ENTIRE purpose of a world file and -meta
>> > packages.
>>
>> a) I've never used the meta packages, but selected my KDE apps on purpose
>
> You missed the part where the user clearly states earlier that he DOES use
> -meta packages. With that in mind, any advice you give should be aligned
> to the fact that he is a -meta user
>
>> b) it's a lot easier this way to get rid of the KDE 3 stuff, however you
>> should get drop of the slot again after depclean has been finished
>
> How is it easier? You have to maintain the SLOTs in world yourself because
> the instant you do that portage will not automagically offer to upgrade
> anymore (upgrades within the same slot excepted). And --depclean will NOT
> adjust your SLOTs in world when it's finished. I can't really make sense
> of your last sentence but that is what you seem to imply

Yes, that's what I've said. Drop the slot again after depclean has finished.
Exactly because of the upgrades.

>> > If that's how you want to admin your box,
>>
>> I am using long enough Gentoo that I remember very well the times when
>> portage destroyed the world file completely.
>
> That was long ago and no longer applicable. That bug in portage got fixed,
> so a behaviour on your part to compensate for a bug that is not there is
> outdated behaviour.
>
>> And regenworld put *anything*
>> into world at that time. Therefore I know very well, what should be in
>> this file and what not. There's no magic.
>
> Yes, the only things in world are packages you want that are not
> dependencies of something else already in world. You are advising the user
> to put the dependencies of -meta packages into world

No. I adviced him to add :4.3 to all kde-base/* packages that *are* in
world.

> when the -meta
> package is already there.

It does not matter in this case if the package is -meta or not.

>
> And that is plain silly
>
>> > can I recommend you switch to
>> > sabayon instead?
>>
>> ROFL! So, you mean, if users get too smart, Gentoo is no longer their
>> distribution? Don't be silly.
>
> Erm, you should read the whole thread and realise the bits you missed -
> the bits that make your statements nonsensical

All I did, was offering an alternative method to get rid of KDE 3 using
depclean without the need to identify every package individually.

Feel free to ignore it.

- Jörg
 
Old 11-28-2009, 06:32 PM
Mick
 
Default FIXED: KDE3 removal

On Saturday 28 November 2009 13:22:14 Alan McKinnon wrote:
> On Saturday 28 November 2009 02:01:22 Mick wrote:
> > > To find out what depends on kate, kweather and kfloppy, use the correct
> > > portage tool:
> > >
> > > alan@nazgul ~ $ equery depends -a kate
> > > * Searching for kate ...
> > > kde-base/kdesdk-meta-4.3.1 (>=kde-base/kate-4.3.1:4.3[kdeprefix=])
> > > kde-base/kdesdk-meta-4.3.3 (!kdeprefix ?
> > >
> > > >=kde-base/kate-4.3.3[-kdeprefix]) (kdeprefix ?
> > > >
> > > >=kde-base/kate-4.3.3:4.3[kdeprefix])
> >
> > OK, but I am getting this much - slightly different to yours above:
> >
> > # equery depends -a kate
> > [ Searching for packages depending on kate... ]
> > kde-base/kde-meta-4.3.1 (>=kde-base/kate-4.3.1:4.3[kdeprefix=])
> > kde-base/kdesdk-meta-4.3.1 (>=kde-base/kate-4.3.1:4.3[kdeprefix=])
> >
> > Now, fair enough, I do not have kde-base/kde-meta installed, so nothing
> > wants to pull back in kate when I update world.
>
> That's normal. The pre-defined sets in kde-testing overlay explicitly list
> kate in the @kde set for that reason.
>
> I suppose one could make several useful -meta packages DEPEND on kate, as
> many users want kate and do not want the entire kdesdk package. But that
> causes the same app to appear in more than one -meta package and the devs
> seem to want to avoid that - there is a strict one-to-one mapping between
> what the -meta packages install and what is shipped in the upstream
> tarballs by KDE

Sorry I'm being rather dense with this ... are you saying that the DEPENDs
listed when you run 'equery depends -a kate' are different to mine because you
are running KDE4 from KDE-testing overlay, while I am running stable portage?
--
Regards,
Mick
 
Old 11-28-2009, 06:42 PM
Alan McKinnon
 
Default FIXED: KDE3 removal

On Saturday 28 November 2009 21:32:28 Mick wrote:
> > I suppose one could make several useful -meta packages DEPEND on kate, as
> > many users want kate and do not want the entire kdesdk package. But that
> > causes the same app to appear in more than one -meta package and the
> > devs seem to want to avoid that - there is a strict one-to-one mapping
> > between what the -meta packages install and what is shipped in the
> > upstream tarballs by KDE
>
> Sorry I'm being rather dense with this ... are you saying that the DEPENDs
> listed when you run 'equery depends -a kate' are different to mine because
> you are running KDE4 from KDE-testing overlay, while I am running stable
> portage?
>

No, the contents of the -meta packages are pretty much the same between the
overlay and the official tree (apart from new apps added in the latest KDE
snapshots, and other minor things that get dropped in the new branch of
course).

The kde-testing overlay provides a collection of sets which the portage tree
does not do. The main set explicitly includes kate because it's part of kdesdk
and it's a bit rich to expect all users to install the entire dev suite just
to get a gui text editor.

The official tree has the same situation:

# grep kate /var/portage/kde-base/*-meta*/*4.3.3.ebuild
/var/portage/kde-base/kde-meta/kde-meta-4.3.3.ebuild: $(add_kdebase_dep
kate)
/var/portage/kde-base/kdesdk-meta/kdesdk-meta-4.3.3.ebuild:
$(add_kdebase_dep kate)

# cat /var/portage/kde-base/kde-meta/kde-meta-4.3.3.ebuild
...
RDEPEND="
$(add_kdebase_dep kate)
$(add_kdebase_dep kdeadmin-meta)
...

To give kate to users, it was added to kde-meta, and it's the only explicit
DEPEND in the ebuild, everything else is the smaller -meta packages.

To get kate, you must do one of:
1. emerge kde-meta (or the @kde set)
2. emerge kdesdk (or the @kdesdk set)
3. emerge kate

--
alan dot mckinnon at gmail dot com
 
Old 11-28-2009, 10:51 PM
Mick
 
Default FIXED: KDE3 removal

On Saturday 28 November 2009 19:42:33 Alan McKinnon wrote:
> On Saturday 28 November 2009 21:32:28 Mick wrote:
> > > I suppose one could make several useful -meta packages DEPEND on kate,
> > > as many users want kate and do not want the entire kdesdk package. But
> > > that causes the same app to appear in more than one -meta package and
> > > the devs seem to want to avoid that - there is a strict one-to-one
> > > mapping between what the -meta packages install and what is shipped in
> > > the upstream tarballs by KDE
> >
> > Sorry I'm being rather dense with this ... are you saying that the
> > DEPENDs listed when you run 'equery depends -a kate' are different to
> > mine because you are running KDE4 from KDE-testing overlay, while I am
> > running stable portage?
>
> No, the contents of the -meta packages are pretty much the same between the
> overlay and the official tree (apart from new apps added in the latest KDE
> snapshots, and other minor things that get dropped in the new branch of
> course).
>
> The kde-testing overlay provides a collection of sets which the portage
> tree does not do. The main set explicitly includes kate because it's part
> of kdesdk and it's a bit rich to expect all users to install the entire
> dev suite just to get a gui text editor.
>
> The official tree has the same situation:
>
> # grep kate /var/portage/kde-base/*-meta*/*4.3.3.ebuild
> /var/portage/kde-base/kde-meta/kde-meta-4.3.3.ebuild: $(add_kdebase_dep
> kate)
> /var/portage/kde-base/kdesdk-meta/kdesdk-meta-4.3.3.ebuild:
> $(add_kdebase_dep kate)
>
> # cat /var/portage/kde-base/kde-meta/kde-meta-4.3.3.ebuild
> ...
> RDEPEND="
> $(add_kdebase_dep kate)
> $(add_kdebase_dep kdeadmin-meta)
> ...
>
> To give kate to users, it was added to kde-meta, and it's the only explicit
> DEPEND in the ebuild, everything else is the smaller -meta packages.
>
> To get kate, you must do one of:
> 1. emerge kde-meta (or the @kde set)
> 2. emerge kdesdk (or the @kdesdk set)
> 3. emerge kate

Thank you kindly for persevering - the logic is clear to me now. :-)

--
Regards,
Mick
 

Thread Tools




All times are GMT. The time now is 02:05 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org