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

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 one restriction:
- 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
  those compatible.
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 security/virus scanners).

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 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.

cu,
sven



Reply to: