public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Paul de Vrieze <pauldv@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev]  Re: KDE, metapackages, and monolithic packages
Date: Mon, 27 Feb 2006 11:09:21 +0100	[thread overview]
Message-ID: <200602271109.22157.pauldv@gentoo.org> (raw)
In-Reply-To: <44023455.3040906@gmail.com>

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

On Monday 27 February 2006 00:05, Mike Myers wrote:
> Duncan wrote
>
> [deleted]
>
> Thanks a lot for the detailed explanation.
>
> Do you know if there's a way or going to be a way to handle the split
> ebuilds so that reemerging or unemerging a split ebuild will reemerge
> or unemerge the corresponding packages?  It seems like the ebuilds are
> only intended to make installing kde easier, which they do, but it
> doesn't make handle uninstalling or reinstalling a split ebuild very
> easy at all.  Like, if I had kde 3.4 installed and upgraded to 3.5 and
> no longer need 3.4, I can't just do 'emerge -C kde-meta-3.4', or
> something similar if it's the installed with the split metapackage. Or
> if I just wanted to remove some split ebuild, like say kdenetwork, but
> leave the rest, I couldn't do 'emerge -c kdenetwork-meta' to uninstall
> the related packages.
>
> Basically, my concern is that how KDE is installed is quite easily
> handled, but uninstalling or reinstalling is not equally as easy, at
> least in some aspects.
>
> I hope I explain myself well enough, and thanks for your response.

It is a problem that has been present in portage since the beginning. The 
problem is that portage does not do reverse dependency tracking. The idea 
should be that when kde-meta-3.4 is deleted, it finds that there is no 
package anymore that requested the kde-3.4 subpackages. And as such 
portage would delete them. Currently we can not fix this. It has to do 
with the reasons that depclean is "broken". One problem is that currently 
portage does not record which particular versions satisfy a dependency. 
As such removing packages that should not be used, may introduce problems 
with packages that have been linked against it.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 200 bytes --]

  parent reply	other threads:[~2006-02-27 10:12 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-25  8:32 [gentoo-dev] KDE, metapackages, and monolithic packages Mike Myers
2006-02-25  9:06 ` Diego 'Flameeyes' Pettenò
2006-02-25 18:33   ` Mike Myers
2006-02-25 18:44     ` Sebastian Bergmann
2006-02-25 18:45     ` John Myers
2006-02-25 20:07       ` Mike Myers
2006-02-25 20:15         ` Matthijs van der Vleuten
2006-02-26 10:52         ` [gentoo-dev] " Duncan
2006-02-26 23:05           ` Mike Myers
2006-02-27  0:56             ` Richard Fish
2006-02-27 10:09             ` Paul de Vrieze [this message]
2006-02-28  0:13             ` [gentoo-dev] " Duncan
2006-02-25  9:06 ` [gentoo-dev] " Petteri Räty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200602271109.22157.pauldv@gentoo.org \
    --to=pauldv@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox