Gentoo Archives: gentoo-dev

From: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets
Date: Sun, 28 Sep 2008 23:03:09
Message-Id: 20080929000257.7bfd0905@snowmobile
In Reply to: Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets by Zac Medico
1 On Sun, 28 Sep 2008 15:56:27 -0700
2 Zac Medico <zmedico@g.o> wrote:
3 > As I've tried to explain, the an ebuild which exhibits
4 > PROPERTIES=set doesn't necessarily have to behave any differently
5 > than a meta-package currently does. What we would do is create a
6 > configuration that maps the set-property ebuild into set space. For
7 > example, `emerge kde-meta` would behave as as normal meta-package
8 > currently does, and `emerge @kde-meta` would reference the same
9 > package as a set and could thereby trigger different behavior which
10 > is appropriate for a set.
11
12 ...and what would that behaviour be? What does a PDEPEND mean for a
13 set?
14
15 > > Here's an alternate proposal: Repositories can ship sets via files
16 > > in sets/*.conf. The format is as described in [1]. In configuration
17 > > files, operations applied to a set are applied to anything matching
18 > > any spec listed in that set (or any set that set contains, and so
19 > > on). On the command line, sets and non-sets cannot be mixed, and
20 > > multiple sets cannot be specified.
21 > >
22 > > [1]: http://paludis.pioto.org/configuration/sets.html
23 > >
24 >
25 > Perhaps can use something like you've got there in addition to the
26 > PROPERTIES=set approach.
27
28 Why the need for multiple solutions at all? PROPERTIES=set is too weird
29 and involves too much nonsensical behaviour to be useful.
30
31 --
32 Ciaran McCreesh

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies