From: Zac Medico <zmedico@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: jmbsvicetto@gentoo.org
Subject: Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets
Date: Mon, 29 Sep 2008 12:52:03 -0700 [thread overview]
Message-ID: <48E131E3.80103@gentoo.org> (raw)
In-Reply-To: <200809291713.30783.bo.andresen@zlin.dk>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bo Ørsted Andresen wrote:
> On Monday 29 September 2008 01:37:03 Zac Medico wrote:
>>> Why the need for multiple solutions at all? PROPERTIES=set is too weird
>>> and involves too much nonsensical behaviour to be useful.
>> I don't see the PROPERTIES=set approach as being worse than any
>> other approach for package set definition. It has lots of advantages
>> because of the way that it fits into the existing ebuild framework
>> like virtual ebuilds do [1], allowing it to leverage all of the
>> existing features of the framework (including package.use) and also
>> allowing it to leverage the tools that have been designed to work
>> with the framework.
>>
>> [1] http://www.gentoo.org/proj/en/glep/glep-0037.html
>
> I really don't see the advantages of fitting 'into the existing ebuild
> framework like virtual ebuilds do'. Can you name any real advantages to it?
This idea initially came up when Jorge (jmbsvicetto) mentioned that
he had used a package set to replace a meta-ebuild in the
desktop-effects overlay, and then users complained that the set did
not supporting the USE conditionals that the previous meta-ebuild
had supported.
Perhaps we can support USE conditionals in sets, but this also seems
to mean that we will need a package.use analog that applies to
package sets. Assuming that we'll need a package.use analog, we
might view the act of replacing meta-packages with sets as a sort of
"throwing the baby out with the bath water" scenario in sense that
meta-packages have lots of useful features and the only reason to
migrate them to sets would be take advantage of the unique features
which sets have to offer. So, rather than force a complete
migration, we may want to consider integrating meta-packages into
the sets framework.
> Having virtuals as ebuilds makes sense because ebuilds need to depend upon
> them. But I can see no decent use case for letting a non-set ebuild depend
> upon a set. As far as I'm concerned sets are merely a convenience for users.
> It allows them to install, reinstall (mostly of interest for scm ebuilds),
> keyword, unmask, set use flags for or uninstall a set of packages.
The "set use flags" part is interesting. If that's the case, it
seems somewhat ambiguous to use sets to "set use flags" and also
allow sets to contain USE conditionals. Supposing that we do allow
both, are we going to create some analog of package.use for sets, or
not? If we do create such an analog, how would it apply to nested
sets? Should nested sets be able to have separate USE conditional
settings from the sets that nest them?
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkjhMeIACgkQ/ejvha5XGaN5EgCgp/KWDienRceXkzV5GX4u9wZp
oYEAnRZ7Z8BErZGRNe6muf7fPRLlW/bQ
=RFAJ
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2008-09-29 19:52 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-28 0:21 [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets Zac Medico
2008-09-28 15:24 ` Marius Mauch
2008-09-28 17:42 ` Zac Medico
2008-09-28 20:26 ` Ciaran McCreesh
2008-09-28 20:44 ` Zac Medico
2008-09-28 20:32 ` Ciaran McCreesh
2008-09-28 20:53 ` Zac Medico
2008-09-28 21:01 ` Ciaran McCreesh
2008-09-28 22:11 ` Zac Medico
2008-09-28 22:28 ` Ciaran McCreesh
2008-09-28 22:56 ` Zac Medico
2008-09-28 23:02 ` Ciaran McCreesh
2008-09-28 23:37 ` Zac Medico
2008-09-29 15:13 ` Bo Ørsted Andresen
2008-09-29 19:52 ` Zac Medico [this message]
2008-09-30 4:47 ` Jorge Manuel B. S. Vicetto
2008-09-30 5:31 ` Zac Medico
2008-10-01 4:35 ` [gentoo-dev] " Ryan Hill
2008-10-01 16:37 ` Zac Medico
2008-10-02 2:51 ` Jorge Manuel B. S. Vicetto
2008-10-04 6:05 ` Ryan Hill
2008-10-04 6:42 ` Ryan Hill
2008-10-04 17:17 ` Zac Medico
2008-10-05 17:55 ` Ryan Hill
2008-10-13 2:11 ` Steve Long
2008-10-02 12:19 ` Robert Bridge
2008-09-29 2:52 ` Duncan
2008-09-29 6:40 ` Zac Medico
2008-09-29 11:52 ` Duncan
2008-09-29 6:04 ` [gentoo-dev] " Rémi Cardona
2008-09-29 6:33 ` Zac Medico
2008-09-29 19:52 ` [gentoo-dev] " Steve Long
2008-09-29 20:28 ` Zac Medico
2008-09-29 20:42 ` [gentoo-dev] " Steve Long
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=48E131E3.80103@gentoo.org \
--to=zmedico@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=jmbsvicetto@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