Re: about volatile.d.o/n
paddy [u] wrote on 12/10/2004 18:14:
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,
would that be 'have to' as in 'MUST'?
Not really a good definition, but explains what I have in mind:
If package A is updated, for it to still keep compatibility, the
following needs to be fulfilled:
Any pre-existing piece of software (let's call it X) which interfaces
with A must stay fully functional. New features may be added to A and
might not be available via the original interface, but any feature
previously available must still work in the same way (less bugs being
fixed). This also means that spelling mistakes in the C locale must be
preserved (they may get fixed in other locales though, including en_US)
as well as any (possibly even weird) output formatting.
That last sentence also implies that any script using the commandline
interface of A must reset LC_ALL and LANG to "C" or unset it. Otherwise
the output format and wording might change from one revision to the
other. This is good practise anyway, since you couldn't rely on a
specific output formatting or wording without specifically setting a
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! ;)
<grin> It wasn't meant that way. But I think that locally written
scripts shouldn't directly use the Perl module API (as in
Mail::SpamAssassin for example) but use the commandline interface instead.
However, as far as possible,
what is the basis for the trade-off.
You mean where I would draw the line for that? I would want to decide
that case-by-case. If the change to the API is minimal and the work for
avoiding it is tremendous (or other reasons make it important to
incorporate that change), it seems wise to allow it in.
they _should_ also keep those compatible.
so that's just a bug then?
??? You mean the incompatibility? Suppose so.
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
This is part of the definition of compatible?
In a way, yes. see explanation above. The addition should interfere with
existing interfaces as little as possible.
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).
API is an application programming interface. So it is not interfering
with scripting interfaces (aka commandline interfaces) ;-)
Actually I think that any machine readable input/output of a program (at
least when called with the C locale selected) is regarded by many people
as an API. I don't think so, but I think it should be handled in a
similar way, but with rules a (very) little less strict.
Sven, you're clearly having a good crack at that here.
Sounds like a compliment to me. thanks. :-)
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.
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).
Yes, staying close to upstream makes it easier to backport their
security fixes for certain. But depending on the release practise of
upstream, it might not be advisable to always simply update to their
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.