1 |
The problem you are describing here is precisely the problem that my |
2 |
suggestion addresses. |
3 |
|
4 |
'emerge -u security' would ONLY upgrade the package to the SAME |
5 |
version-revision... if there is a newer security-bumped package... |
6 |
|
7 |
For instance: |
8 |
|
9 |
small-package-0.1 (on system) |
10 |
small-package-0.1-r1 (in portage) |
11 |
|
12 |
lets say 0.1-r1 has a security problem (but not 0.1)... we release an |
13 |
updated ebuild as: |
14 |
|
15 |
small-package-0.1-r1-s1 |
16 |
|
17 |
'emerge -u security' for you would NOT update small-package since it |
18 |
doesn't have a security problem. |
19 |
|
20 |
I don't see how the package's dependencies should be relevant at all |
21 |
because you would already satisfy them (how else would the package |
22 |
already be installed?). Because of the nature of the security bumps, |
23 |
all the packages of the same revision level would have the same |
24 |
dependencies... after all, this is just security hole plugging, not |
25 |
feature addition... |
26 |
|
27 |
On Wed, 2004-02-18 at 03:45, Calum wrote: |
28 |
> On Wednesday 18 February 2004 2:57 am, Jeremy Huddleston wrote: |
29 |
> |
30 |
> > |
31 |
> > portage could implement 'emerge security' which only updates packages |
32 |
> > that have a new -s# (security bump) available. |
33 |
> |
34 |
> I still feel that breaking this up a little more would benefit more people. |
35 |
> |
36 |
> Maybe I have app-misc/small-app-0.0.1 on my server for whatever reason. |
37 |
> A symlink vulnerability is discovered in it, which allows a local user to get |
38 |
> gid = games. |
39 |
> This is where the remote-root and local-root ideas would be good. |
40 |
> I would prefer it that when I ran my scripted emerge sync && emerge -up |
41 |
> remote-root (or whatever) that the output would be blank if there weren't any |
42 |
> relevant updates. |
43 |
> |
44 |
> I run /usr/bin/emerge sync > /dev/null && /usr/bin/emerge -up system | grep |
45 |
> ebuild each night at about 4.30, and when I get in I review the list of |
46 |
> updates. |
47 |
> If every time I ran emerge -up security I saw this little small-app-0.0.1 that |
48 |
> needed upgrading, it would just be irksome. |
49 |
> Sure, yeah, I know, upgrade it, but lets say that it relies on |
50 |
> lib-used-by-everyother-prog being a certain version. |
51 |
> |
52 |
> I really think that remote-root and local-root would provide more granularity, |
53 |
> and allow people to decide. Who's to say what would go under the "security" |
54 |
> banner? |
55 |
> |
56 |
> The more choice the better, IMHO. |
57 |
> |