1 |
On 9-Feb-04, at 11:57 AM, Marius Mauch wrote: |
2 |
|
3 |
> On 02/09/04 Ixion wrote: |
4 |
> |
5 |
>> I second that! I've been doing 'emerge -u world's on my web server at |
6 |
>> home and the fileservers here at work, and like Mark, do not feel |
7 |
>> comfortable with this. I also don't have a lot of time to dig around |
8 |
>> and find out why there was an update (unless there's an easy way to do |
9 |
>> this??). |
10 |
>> |
11 |
>> I think 'emerge -u -L1 world' is an awesome idea! :) |
12 |
> |
13 |
> But not really possible to implement as the importance is rather |
14 |
> subjective and dependant on the context. Example: |
15 |
> |
16 |
> foo-1.0.1 is a trivial update to foo-1.0.0 |
17 |
> foo-1.0.2 is a trivial update to foo-1.0.1 |
18 |
> |
19 |
> now is foo-1.0.2 also a trivial update to foo-1.0.0 ? |
20 |
> You'd have to define the importance against all previous versions or |
21 |
> find a very intelligent algorithm that makes everyone happy. |
22 |
|
23 |
Not really. if you look at the way freshmeat.net setups up their |
24 |
priorities for updates then it all makes more sense and I would love to |
25 |
see a 'vitality' or whatever you want to call it into the metadata. |
26 |
Their priorities are always referred against the previous version of |
27 |
the code in question. If you do want to compare against the current |
28 |
installation it's simple math iterating over available versions, but I |
29 |
think this is getting overly complicated for nothing, the primary focus |
30 |
here should ideally be that security updates get noticed and updated in |
31 |
a timely matter without having to track things by hand. |
32 |
|
33 |
|
34 |
> Also who should define the importance ? The ebuild maintainer might |
35 |
> have |
36 |
> a different opinion about what's important than you (not to mention |
37 |
> that |
38 |
> it just adds one more piece of information that has to be maintained). |
39 |
|
40 |
As far as developers setting the vitality of the update, it would be |
41 |
simple enough to lay out basic guidelines (there will always be |
42 |
judgment calls that will vary but at least we get in the ballpark) that |
43 |
they could follow as a template, and I can't think of a better person |
44 |
to set the vitality of the update than the developer maintaining the |
45 |
package (who is most cases should be fairly intimate with the package |
46 |
in question). |
47 |
|
48 |
Even if it just went as far as marking crucial security updates with |
49 |
some sort of flag it would be better than where we are at right now |
50 |
doing things by hand, and at the very least these types of very |
51 |
important security updates should have some way of setting themselves |
52 |
as a priority and notifying the user that there are updates available |
53 |
that if you don't do could compromise the security of your machine. |
54 |
|
55 |
Mark |
56 |
|
57 |
|
58 |
-- |
59 |
gentoo-security@g.o mailing list |