1 |
On Thu, 28 Jun 2007 21:03:54 -0700 |
2 |
Ned Ludd <solar@g.o> wrote: |
3 |
|
4 |
> On Fri, 2007-06-29 at 05:07 +0200, Marius Mauch wrote: |
5 |
> > Please reply on gentoo-portage-dev, _not_ on gentoo-dev, thanks. |
6 |
> > |
7 |
> > One missing feature in portage is the lack of package sets. Before |
8 |
> > we (re)start working on that however I'd like to get some feedback |
9 |
> > about what properties/features people would expect from portage |
10 |
> > package set support. |
11 |
> > Some key questions: |
12 |
> > |
13 |
> > - should they simply act like aliases for multiple packages? E.g. |
14 |
> > should `emerge -C sets/kde` be equivalent to `emerge -C kdepkg1 |
15 |
> > kdepkg2 kdepkg3 ...`? Or does the behavior need to be "smarter" in |
16 |
> > some ways? |
17 |
> |
18 |
> I like the alias way acting simply as a metapkg. |
19 |
|
20 |
Well, mind that a very simple alias implementation as outlined above |
21 |
would for example unmerge kdepkg3 even if it was merged explicitly. |
22 |
|
23 |
> > - should sets be supported everywhere, or only in selected use |
24 |
> > cases? (everywhere would include depstrings for example) |
25 |
> |
26 |
> Please NO. emerge.py should know about sets but ebuild.py should be |
27 |
> oblivious to them. package sets as you are proposing imo should be |
28 |
> limited to portage only. By putting package sets in ebuild depstrings |
29 |
> we would be effectively forcing all other pkg managers to support the |
30 |
> feature. I don't think we should do that. |
31 |
|
32 |
What about config files (package.*) or other sets? |
33 |
|
34 |
> > - what use cases are there for package sets? Other than the |
35 |
> > established "system" and "world", and the planned "all" and |
36 |
> > "security" sets. |
37 |
> |
38 |
> Assuming you guys run with with the simple alias method I don't see |
39 |
> how 'security' can fit into this. |
40 |
|
41 |
Simple: the list of atoms would be assembled dynamically by checking |
42 |
the available GLSAs, similar to how the "affected" target works in |
43 |
glsa-check. But lets keep the backend implementation details out for |
44 |
now. |
45 |
|
46 |
Marius |
47 |
|
48 |
-- |
49 |
Public Key at http://www.genone.de/info/gpg-key.pub |
50 |
|
51 |
In the beginning, there was nothing. And God said, 'Let there be |
52 |
Light.' And there was still nothing, but you could see a bit better. |