Scripsit Florian Weimer <[EMAIL PROTECTED]>
> >> Can volatile receive critical updates which are usually not applied to
> >> stable because backports are not available for some reason?
> Mozilla, GnuPG, and maybe even PHP 4, depending on sarge's lifetime.
> Other complex packages can easily enter this state, too, especially
> when sarge has been around for a year or two.
I would advise not trying to overloade volatile with too many
meanings. A backport of a new Mozilla release is something vastly
different from new rules for a spam filter, and I see little value in
lumping them together in the same add-on repository. I would like to
see a volatile with a very strict mandate:
1. Volatile is a means for *pushing* updates to stable
installations, where such updates are necessary for *preserving*
the utility of packages due to changes of the outside world.
2. "Necessary for preserving the utility" should be judged under
the assumption that the machine that runs stable does not itself
change. (I.e., appeals to "this is needed for modern hardware"
don't count).
3. No update pushed through volatile should ever change any
user interfaces or programmatic interface. (How paranoid
developers are expected to be in ensuring this is negotiable,
but it must at least be the *goal* that no interfaces change.)
The goal should be that I, as a user, can add volatile to my
sources.list and periodically do an apt-get upgrade - without risking
to suddenly have my web browser updated to a new major release where
it starts behaving differently, all my users' preferences get out of
kilter, etc. If I run a web browser on a stable machine, it is because
I am satisfied with its behavior and capabilities. If I want a newer
one, I can go to a regular backports repository and pick one by hand.
I do not want to get a new version pushed at me simply because it
becomes available. If I wanted that kind of behavior I would run
testing or unstable, not stable.
An update of mozilla-browser would be appropriate for volatile if it
did not change the upstream codebase, but, say, updated the default
SSL root certificate set in response to announcements from a
well-known CA.
An update that fixed the default style sheet to include new tags
from XHTML 2.1, assuming that it was possible without code changes,
would be borderline. Anything more involved than that - no thanks.
--
Henning Makholm "Punctuation, is? fun!"
