Re: about volatile.d.o/n
On Mon, Oct 11, 2004 at 05:06:21PM +0100, Henning Makholm wrote:
> Scripsit Florian Weimer <fw@deneb.enyo.de>
>
> > >> 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.
Agreed. I think its hard enough establishing a simple meaning.
But these issues have been bubbling and motivating in this area
for some time, perhaps there will be more room at the inn soon?
> A backport of a new Mozilla release is something vastly
> different from new rules for a spam filter,
To be fair, the issue is that if were just rules, there wouldn't
be a need.
> and I see little value in
> lumping them together in the same add-on repository.
risky. but there may be some synergies. And then there is the
potential cost of a profusion of little repositories.
Whatever the solution is to the mozilla problem, there does at least
appear to be consensus that there has been one.
> 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.
Of course the outside world is where new hardware becomes available ;)
> 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).
Excellent. This really makes the distinction.
Not that I care one way or another whether drivers can enter volatile,
but the lack of a good distinction was really bothering me.
> 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.)
This is still blurry for me, although I agree with your example.
Let me offer examples of real-life changes and their impact:
MailScanner can be configured to send mail to an admin account warning
of various events. I filter these with procmail. Recently these
warnings changed. I would not want a volatile maintainer to be
hamstrung in such a case if no package in debian uses the interface:
I made the mess, I can fix it (and I will, soon ... :)
(Also: which would you rather have backward-compatibility or
forward-compatibility? depends on how much past you have and what
future you see)
Clearly the names of virus identifications sometimes change.
This is expected. I would say that the interface is _defined_ as volatile.
But these are at one extreme, clamav not dragging sendmail into the
archive is at another, and you are identifying important ground in
the middle.
> The goal should be that I, as a user, can add volatile to my
> sources.list and periodically do an apt-get upgrade
Personally, if use it (as I hope to), it will be only for specific packages.
> - 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.
This sounds quite hectic, I'm begining to feel all dizzy.
> 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.
Ah, that's much better.
Playing the devil's advocate:
Someone's going to say "so don't do that then" aren't they.
Are you saying you have a use for a volatile mozilla, or simply
that you see potential problems? If it's the latter, then I
agree, you have identified a potential problem area.
Also: for a web-browser, yes. For applications in more voltile domains I'm
willing to be a little more flexible. But that's just me.
Is it practical, or even possible, to identify the use-cases for a
web-browser in volatile, to shed more light on what users actually
want? Hell, do we care what users want (only kidding folks!)
> 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.
It would seem a shame to have to do a whole mozilla-browser package
just for that.
> 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.
Too technical for me. I think what you're saying is you don't
want the browser to change very much. I don't know how important
fixing 'the default style sheet to include new tags from XHTML 2.1'
is, but it sounds pretty unimportant to me. Presumably, security
fixes are more important. The absence of security support seems
to be a great motivator for the appearance of mozilla in all this.
<ducks>
If there is a case for mozilla in volatile, it will need to be made
on it's own merits. I think that case is already hard enough to make.
I don't see any need to place obstacles in the way just in case.
And I'm concerned that those obstacles might ultimately get in the way
of packages _in_ volatile (when we have some).
Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall
Reply to: