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

[gentoo-portage-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-portage-dev] [RFC] Properties of package sets

[Ned Ludd]

On Fri, 2007-06-29 at 05:07 +0200, Marius Mauch 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?

I like the alias way acting simply as a metapkg.

> - 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)?

Mixed feelings about this. At first I assumed the syntax would be that
pretty much of package.mask etc.. But I can for sure see the advantage
of something as tad more complex of use conditionals being handy.
USE="foo bar -nls" ROOT=/baz emerge sets/livecd.
with the file being defined as nls? ( dislike/gettext ) but at the same
time this is probably when we should use a proper ebuild as a metapkg.

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

Please NO. emerge.py should know about sets but ebuild.py should be
oblivious to them. package sets as you are proposing imo should be
limited to portage only. By putting package sets in ebuild depstrings we
would be effectively forcing all other pkg managers to support the
feature. I don't think we should do that.


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

Assuming you guys run with with the simple alias method I don't see how
'security' can fit into this. 


> - how/where should sets be stored/distributed?
> 
> Please reply on gentoo-portage-dev, _not_ on gentoo-dev, thanks.
> 
> Marius
> 

-- 
gentoo-portage-dev@gentoo.org mailing list

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

[Marius Mauch]

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

On Thu, 28 Jun 2007 21:03:54 -0700
Ned Ludd <solar@gentoo.org> wrote:

> On Fri, 2007-06-29 at 05:07 +0200, Marius Mauch 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?
> 
> I like the alias way acting simply as a metapkg.

Well, mind that a very simple alias implementation as outlined above
would for example unmerge kdepkg3 even if it was merged explicitly.

> > - should sets be supported everywhere, or only in selected use
> > cases? (everywhere would include depstrings for example)
> 
> Please NO. emerge.py should know about sets but ebuild.py should be
> oblivious to them. package sets as you are proposing imo should be
> limited to portage only. By putting package sets in ebuild depstrings
> we would be effectively forcing all other pkg managers to support the
> feature. I don't think we should do that.

What about config files (package.*) or other sets?

> > - what use cases are there for package sets? Other than the
> > established "system" and "world", and the planned "all" and
> > "security" sets.
> 
> Assuming you guys run with with the simple alias method I don't see
> how 'security' can fit into this. 

Simple: the list of atoms would be assembled dynamically by checking
the available GLSAs, similar to how the "affected" target works in
glsa-check. But lets keep the backend implementation details out for
now.

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-portage-dev] [RFC] Properties of package sets

[Brian Harring]

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

On Thu, Jun 28, 2007 at 09:03:54PM -0700, Ned Ludd wrote:
> On Fri, 2007-06-29 at 05:07 +0200, Marius Mauch wrote:
> > - should sets be supported everywhere, or only in selected use cases?
> > (everywhere would include depstrings for example)
> 
> Please NO. emerge.py should know about sets but ebuild.py should be
> oblivious to them. package sets as you are proposing imo should be
> limited to portage only. By putting package sets in ebuild depstrings we
> would be effectively forcing all other pkg managers to support the
> feature. I don't think we should do that.

Seconded on the 'no'; aside from it screwing up parsing, that's 
*system* configuration- meaning it's not part of a repository data 
set, thus the repository data set should in no way depend on it.

~harring

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

[gentoo-portage-dev] 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 --]