public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Dan Armak <danarmak@gentoo.org>
To: gentoo-dev@robin.gentoo.org
Subject: Re: [gentoo-dev] GLEP ??: Metapackages
Date: Sun, 6 Mar 2005 21:20:26 +0200	[thread overview]
Message-ID: <200503062120.38637.danarmak@gentoo.org> (raw)
In-Reply-To: <1110132737.9219.10.camel@localhost>

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

On Sunday 06 March 2005 20:12, Stephen Bennett wrote:
> On Sun, 2005-03-06 at 19:40 +0200, Dan Armak wrote:
> > It's a cool idea. What's missing in the proto-GLEP is an explanation of
> > why you can't do this with a normal ebuild (that doesn't install any
> > files), and need the new concept of metapackages.
>
> The idea is that a metapackage, unlike a normal ebuild, doesn't exist in
> the installed package db, and its deps are always inspected when it
> turns up in the depgraph. That means that you avoid the situation where
> you merge package A, which depends on virtual/x11, and then pulls in
> xorg-x11. Then, for whatever reason, you unmerge xorg, and virtual/x11
> is still in the vdb, so the next app you merge that deps on it will
> break. That was explained in the -dev thread I linked; I probably should
> add an explanation into the GLEP.
OK. That would be fixed (for all ebuilds) by RDEPEND support on unmerge.

> > Also, the GLEP says: "On a side note, this system of metapackages would
> > provide an implementation of 'package sets' as proposed in GLEP 21 [2]_."
> >
> > I don't see how that would happen. A package set exists to install all of
> > a list of packages, while a virtual/metapackage exists to install one of
> > a list of (often mutually exclusive) packages. These are very different
> > goals. How would metapackages help with sets any more than ordinary
> > ebuilds already do?
>
> Since the metapackage has some arbitrary DEPEND string that has to be
> met, there's no reason why this couldn't require all packages reckoned
> to be part of a set, rather than one of the packages reckoned to provide
> a virtual.
Yes, but you can already do this with an ebuild. The only difference is again 
the RDEPEND issues...

Well, this should be mentioned in the GLEP IMO.

BTW, the new functionality I think we really need for sets (which isn't 
specified in GLEP 21) is for the unmerge command to act on an entire set. 
E.g. to unmerge all of the (slotted) KDE 3.4 after installing 3.5.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

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

  reply	other threads:[~2005-03-06 19:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-01 22:15 [gentoo-dev] GLEP ??: Metapackages Stephen Bennett
2005-03-02 12:30 ` Paul de Vrieze
2005-03-02 20:58 ` Alec Warner
2005-03-03  0:14   ` James Northrup
2005-03-06 17:40 ` Dan Armak
2005-03-06 18:12   ` Stephen Bennett
2005-03-06 19:20     ` Dan Armak [this message]
2005-03-07 10:26 ` Thomas de Grenier de Latour
2005-03-07 17:45   ` Stephen Bennett
2005-03-15 12:21 ` Thomas de Grenier de Latour

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=200503062120.38637.danarmak@gentoo.org \
    --to=danarmak@gentoo.org \
    --cc=gentoo-dev@gentoo.org \
    --cc=gentoo-dev@robin.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