On Tue, Oct 12, 2004 at 05:02:23PM +0200, Sven Mueller wrote: > Henning Makholm [u] wrote on 12/10/2004 16:05: > > >>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; I would say it > >is not even relevant. Admins of un*x systems are *supposed* to write > >a truckload of local scripts to adapt their system to their wishes. > >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. > > If you put it that way, I have to agree with you. However, I would make > one restriction: > - packages in volatile have to keep their commandline (both input and > output) interfaces compatible,
would that be 'have to' as in 'MUST'? define compatible. > but may change C/Python/Perl > interfaces if no unresolved incompatibility in the whole of Debian is > created that way. Yeah I've never liked those C/Python/Perl people either, not enough soldering irons! ;) > However, as far as possible, what is the basis for the trade-off. > they _should_ also keep those compatible. so that's just a bug then? > An exception can be made (like you said) if a change in interface is > needed to close a security whole. Taken as read. > Another reason for exception is an > addition to the interface (as little interfering as possible) to allow > scanning for and reporting of new security holes or viruses (for > security/virus scanners). This is part of the definition of compatible? > >If upgrading will break existing interfaces, then "when" means "after > >the current testing freezes and is released as stable". > > Like I said above, I generally agree. But I would only expect scripting > interfaces in the meaning of commandline interfaces to remain > compatible. If a sysadmin writes scripts which depend on an actual API, > I think it is reasonable for him(/her) to track changes in the APIs > (s)he is using and/or to mark the packages containing those APIs as hold. more generally, and a point I was trying to make before: If one wishes to make guarantees about APIs then it might be good to identify the APIs. It is surprising how much people's opinions can vary in the edge-cases, and too much hand-waving is bad for the circulation. (okay, so I made the last part up). Sven, you're clearly having a good crack at that here. > >>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. > > OK, I would like to see it implemented approx. like this (names subject > to change): > - volatile.d.o: security and virus scanners, anti-spam software and > similarly fast moving software needed mostly on servers > - backports.d.o: New (versions of) user interface software (new KDE, new > Mozilla and the like) > Both might need security team support, which I would think is difficult > for the later. Depending on how big it is I imagine. Certainly, when staying close to upstream versions, one hopes to have a relatively easy time applying security fixes (or even just upgrading to the next version). I'm inclined to think that packages like mozilla belong in stable or backports, because I can't see why they _have_ to be volatile. I don't think being immature software would make a good criterion for entry. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
