On Tue, Oct 12, 2004 at 03:05:05PM +0100, Henning Makholm wrote: > Scripsit paddy <[EMAIL PROTECTED]> > > On Mon, Oct 11, 2004 at 07:22:15PM +0100, Henning Makholm wrote: > > > Scripsit paddy <[EMAIL PROTECTED]> > > > > > To be fair, the issue is that if were just rules, there wouldn't > > > > be a need. > > > > Why not? > > > Well, the argument goes: > > > that can be done out-of-band, > > 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. These files do not come through the usual package management: you don't apt-get them. Similar situtations exist for other software with this kind of volatility. > > but some updates involve changes > > or additions to the engine. There is a class of such software. > > 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. > > SA3 has been on the cards for some time now. Is there a policy around > > name changes at these times? could you have pinned (<<3.0) ? > > Not according to my understanding of apt pinning. Pity, that would be a nice feature. > 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! :) > That's what "stable" means. I'd go along with that. I don't know what "volatile" will eventually mean. Clearly it can't mean exactly the same as "stable", but it would be a shame if it couldn't provide a service in the "I don't how it works, it just works" class to users of stable. That isn't however my personal interest. > > At the end of the day, I'm not certain exactly what you wanted protecting > > from, > > See the long thread about spamassassin3. The highlight is that the new > version has a non-backwards-compatible API which makes certain other > software stop working. I'll go and do that, I had been skipping it ... > I did not personally have any local scripts that depended on the old > API, but I might have had. > > > but it's hard to be certain that volatile would give it to you. > > After all the point is to get (at least some) changes. > > The point is to get improved *classification* without changing the > *interfaces*. For me the point is to achieve function. Naturally one tries to avoid bugs and breakage. The standards of QA to which given software are important factors in the selection of that software. Volatile should have clear standards of QA so that users know what to expect, and mainatiners know what they are aiming for. I don't know how much of that it will be possible to write upfront, and how much will have to be learn along the way. > > > Clearly, but the *format* in which the virus scanner reports its > > > findings should stay stable. > > > You'll get no argument from me on the priciple of that. > > But what is stable? What if a format needs extending to take account > > of some new circumstance? > > Then a decision has to be made respecting the users' interest in > having whatever local scripts they are using keep working. Sounds reasonable to me. > > For instance, suppose there are Packages A and B in volatile. > > (A) has an interface (1) that is only used by (B) in the whole of debian. > > "In the whole of Debian" is not the only concern here; Agreed, and I did attend to the question of user scripts further down. > I would say it is not even relevant. I think it could prove to be a consideration. > Admins of un*x systems are *supposed* to write > a truckload of local scripts to adapt their system to their wishes. I only use a soldering iron. scripts are for wimps. invoking trucks doesn't make them any less wimpy. ;) > That's the way it works. And our commitment in calling stable "stable" > is that those local scripts will keep working across security updates, > unless breaking them is necessary to close a hole. Similarly, if > volatile is to be any value added over pinning unstable or testing, > it must respect the same commitment. Okay. The purpose of security is to close holes. Given that volatile identifies it's purpose, I say we apply a similar measure. Without the _possibility_ of trading breakage against purpose, we run the risk of futility. But I agree, breakage should not be introduced randomly. I happen to believe that an excessive aversion to controlled breakage can result in more consequential 'accidental' breakages. There is almost always a trade-off. > > but the case for eventually upgrading to (1+) is > > compelling: it is only a question of when and how. > > 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' ? Or do you mean testing-volatile and stable-volatile? with a shorter release cycle? In which case, it sounds reasonable. > > You've said mozilla belongs in backports, which I'll take to mean: > > mozilla does not belong in volatile. > > I'm saying that *new upstream versions* of mozilla with hundreds of > little interface changes, new preferences file formats, et cetera, > does not belong in volatile. You'll get no argument from me there, but only because I have no interest in seeing mozilla in volatile. If you s/mozilla/spamassassin/ I might want to argue the point. > > So you're not advocating mozilla in volatile. It may be that someone > > will come along that will advocate it in a compelling fashion, but > > I'm not holding my breath. Until then, if no one is building it, > > then what is there to knock down ? > > I do not understand that question either. Why are we talking about mozilla? > > Concrete example: I care about virus detection in the first two weeks, > > and even more so in the first few hours. To me not detecting a virus, > > purely because someone is correcting spellings would be downtime. > > (of course, if it's because _I'm_ too busy or too lazy, that's a > > different matter ! ;) > > I'm not sure what consequences this example has for what should and > what should not be accepted in volatile. If the volunteer who would be > preparing a rule update would rather use his time correcting > spellings, we cannot force him. But that is probably not what you're > getting at? No, I'm more than happy and gratefull for any maintainer giving his/her time doing something usefull, that other people can use. I think the point of the concrete example is to be upfront about my interests, and that (I hope) I don't have unreasonable expectations of volatile, because I am not expecting volatile to do this for me. That is to say: I don't expect my particular workload to be the template for volatile, this example need not have consequences for volatile. (of course, it would be nice ...) Also, it might make it easier for you to understand where some of my wilder positions are coming from and to discount me quicker :) Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
