Re: about volatile.d.o/n
On Tue, Oct 12, 2004 at 10:26:34PM +0100, Henning Makholm wrote:
> Scripsit paddy <paddy@panici.net>
> > On Tue, Oct 12, 2004 at 03:05:05PM +0100, Henning Makholm wrote:
>
> > > But isn't volatile.d.o supposed to *be* the out-of-band mechanism
> > > (whatever out-of-band means here)?
>
> > No. clamav virus signatures, for example, can be maintained by a program,
> > freshclam, that downloads database updates from upstream.
>
> I know that, but as far as I under stande, the whole point of volatile
> is to replace exactly that with a situation where each maintainer does
> not have do program his own freshfoo system (and worry about finding a
> location to download from that is known in advance to stay availbale
> throughout the entire lifetime of the next stable release).
We have different understandings. Some have expressed interest in using
volatile in this way, and I don't see any objection to that, provided
that it is a good way to solve the specific problem in hand. But, that
is not 'the whole point of volatile', which is more as I describe (naturally :)
> > > I don't see how that means that there "wouldn't be a need" for rule
> > > updates.
>
> > See above. The consensus seems to be that it would be undesirable to
> > even try to push this data through the regular package-management channel.
>
> Whose consensus is this? The debian-devel feed that reaches me shows
> quite enthusiastic support for pushing rule updates through an aptable
> repository.
Sorry, useless generalisation on my part: 'this data'. Let me try to be
more specific.
Virus definition updates fit in the 'undesirable' category. Thats not
to say some database can't be packaged. Here's a couple of references:
184882DD97@murphy.debian.org
1B6482DEA2@murphy.debian.org
(I'll post a reply with the ml archive web urls, in a hurry just now)
For things like snort and spamassasin, both approaches have value.
For slower moving stuff, like the whois example, the question is more
a case of 'what is a good way?'.
> > > And in any case the point is that I want to run a *stable* box. I
> > > am not keeping consciously track with upstream changes to
> > > "background" software like spam filters, so I didn't *know* that a
> > > 3.0 version was about to happen. A user of stable should be *able*
> > > to remain ignorant about such chages.
>
> > Ah, but you weren't just a user of stable were you?
> > You'd drunk from the forbidden waters of unstable! :)
>
> Because volatile does not currently exist.
>
> > > The point is to get improved *classification* without changing the
> > > *interfaces*.
>
> > For me the point is to achieve function.
>
> Function may disappear totally if the update makes things break.
Yes, different people, different software, different requirements.
For me, a totally broken clamav is almost exactly as usefull as two-week
out-of-date clamav, but that's because I believe that the system that
I use can contain that breakage, so that I am _not_ talking about
sending all the mail to /dev/null.
> > > If upgrading will break existing interfaces, then "when" means "after
> > > the current testing freezes and is released as stable".
>
> > Yes, for stable. Do we want 'just another stable' ?
>
> No, we want a way to push non-breaking data updates to stable users in
> a controlled way. They'll still be stable users, so they still want
> freedom from gratuitous breaking.
A lot of these two threads has been dedicated to painstaking description
of why 'data updates' doesn't cover it.
> > If you s/mozilla/spamassassin/ I might want to argue the point.
>
> Well, I don't want to se an update to spamassassin in volatile if it
> breaks APIs that my scripts use.
We are in broad agreement here.
Please see discussion with Sven and Thomas elsewhere in this thread.
> Raising spam detection rates from 97%
> to 98% is useless if the update makes my mail system go catatonic and
> deliver all incoming mail, spam or not, to /dev/null.
Agreed.
> I run stable on
> my mail server because I *don't* want random breakage, and if not
> having any random breakage means that I'll have do delete a bit more
> of my spam by hand, then so be it.
Fine.
> If I wanted random breakage, I'd run testing on the server. But I don't.
Makes perfect sense to me.
And it all goes towards what you would like volatile to be.
> > Why are we talking about mozilla?
>
> I don't know. You seem to have some kind of point about it, but I
> still cannot fathom what it is.
I suspect its a hangover from earlier in the thread, and that neither
of us is particularly interested in discussing that particular case.
Given that, we'd do better to talk about what we do care about.
That is my point.
Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall
Reply to: