[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: about volatile.d.o/n

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.

Perl 6 will give you the big knob. -- Larry Wall

Reply to: