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

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

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 well-known locale.

 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 security/virus scanners).

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

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


Reply to: