Re: about volatile.d.o/n
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
- packages in volatile have to keep their commandline (both input and
output) interfaces compatible, but may change C/Python/Perl
interfaces if no unresolved incompatibility in the whole of Debian is
created that way. However, as far as possible, they _should_ also keep
An exception can be made (like you said) if a change in interface is
needed to close a security whole. 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
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.
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
- 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.