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.
Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall
Reply to: