List Archive: gentoo-security
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On 9-Feb-04, at 11:57 AM, Marius Mauch wrote:
> On 02/09/04 Ixion wrote:
>> I second that! I've been doing 'emerge -u world's on my web server at
>> home and the fileservers here at work, and like Mark, do not feel
>> comfortable with this. I also don't have a lot of time to dig around
>> and find out why there was an update (unless there's an easy way to do
>> I think 'emerge -u -L1 world' is an awesome idea! :)
> But not really possible to implement as the importance is rather
> subjective and dependant on the context. Example:
> foo-1.0.1 is a trivial update to foo-1.0.0
> foo-1.0.2 is a trivial update to foo-1.0.1
> now is foo-1.0.2 also a trivial update to foo-1.0.0 ?
> You'd have to define the importance against all previous versions or
> find a very intelligent algorithm that makes everyone happy.
Not really. if you look at the way freshmeat.net setups up their
priorities for updates then it all makes more sense and I would love to
see a 'vitality' or whatever you want to call it into the metadata.
Their priorities are always referred against the previous version of
the code in question. If you do want to compare against the current
installation it's simple math iterating over available versions, but I
think this is getting overly complicated for nothing, the primary focus
here should ideally be that security updates get noticed and updated in
a timely matter without having to track things by hand.
> Also who should define the importance ? The ebuild maintainer might
> a different opinion about what's important than you (not to mention
> it just adds one more piece of information that has to be maintained).
As far as developers setting the vitality of the update, it would be
simple enough to lay out basic guidelines (there will always be
judgment calls that will vary but at least we get in the ballpark) that
they could follow as a template, and I can't think of a better person
to set the vitality of the update than the developer maintaining the
package (who is most cases should be fairly intimate with the package
Even if it just went as far as marking crucial security updates with
some sort of flag it would be better than where we are at right now
doing things by hand, and at the very least these types of very
important security updates should have some way of setting themselves
as a priority and notifying the user that there are updates available
that if you don't do could compromise the security of your machine.
firstname.lastname@example.org mailing list