[gentoo-dev] [RFC] Properties of package sets

[gentoo-dev] [RFC] Properties of package sets

[Marius Mauch]

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

Please reply on gentoo-portage-dev, _not_ on gentoo-dev, thanks.

One missing feature in portage is the lack of package sets. Before we
(re)start working on that however I'd like to get some feedback about
what properties/features people would expect from portage package set
support.
Some key questions:

- should they simply act like aliases for multiple packages? E.g.
should `emerge -C sets/kde` be equivalent to `emerge -C kdepkg1 kdepkg2
kdepkg3 ...`? Or does the behavior need to be "smarter" in some ways?

- what kind of atoms should be supported in sets? Simple and versioned
atoms for sure, but what about complex atoms (use-conditional, any-of,
blockers)?

- should sets be supported everywhere, or only in selected use cases?
(everywhere would include depstrings for example)

- what use cases are there for package sets? Other than the established
"system" and "world", and the planned "all" and "security" sets.

- how/where should sets be stored/distributed?

Please reply on gentoo-portage-dev, _not_ on gentoo-dev, thanks.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

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

Re: [gentoo-dev] [RFC] Properties of package sets

[Marius Mauch]

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

On Fri, 29 Jun 2007 05:07:28 +0200
Marius Mauch <genone@gentoo.org> wrote:

> Please reply on gentoo-portage-dev, _not_ on gentoo-dev, thanks.
> 
> One missing feature in portage is the lack of package sets. Before we
> (re)start working on that however I'd like to get some feedback about
> what properties/features people would expect from portage package set
> support.
> Some key questions:
> 
> - should they simply act like aliases for multiple packages? E.g.
> should `emerge -C sets/kde` be equivalent to `emerge -C kdepkg1
> kdepkg2 kdepkg3 ...`? Or does the behavior need to be "smarter" in
> some ways?
> 
> - what kind of atoms should be supported in sets? Simple and versioned
> atoms for sure, but what about complex atoms (use-conditional, any-of,
> blockers)?
> 
> - should sets be supported everywhere, or only in selected use cases?
> (everywhere would include depstrings for example)
> 
> - what use cases are there for package sets? Other than the
> established "system" and "world", and the planned "all" and
> "security" sets.
> 
> - how/where should sets be stored/distributed?

Forgot one question:

- should sets have metadata? (e.g. a description for searching)

There hasn't been much feedback yet, so if you want to add anything now
is your chance, otherwise I'll implement things the way that works
best/is easiest for me, which might be different from what you expect.

Marius

PS: I also accept off-list replies

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

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