Re: about volatile.d.o/n
On Tue, Oct 12, 2004 at 09:44:30PM +0200, Sven Mueller wrote:
> 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'?
>
> Yes.
>
> >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.
This sounds reasonable. I have yet to understand the value of 'no new
command-lines interfaces' as opposed to 'no broken scripting interfaces'.
Preserving specifically the system locale, seems like an excellent
balance, and would go a long way to resolving the mailscanner example
I gave (the output was to changed to give better functionality ...),
I wasn't familiar with this convention, but it seems an excellent example
of where a distro like debian can add value over upstream.
I don't think 'less bugs being fixed' could stand without some qualification
somewhere of what bugs it is acceptable to fix and cause breakage.
> >> 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.
I'm uncomfortable with the form of words, but with you on the intended
destination.
I think requiring absolutely static interfaces is too great a
straight-jacket, but drawing a line like this, so that people know
what to expect, is a good idea. The line seems drawn with the lay of
the land to me.
I imagine that the maintainers could shed much more light on this.
> >> 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.
I wonder if a system where, in the event of breakage being deemed desirable,
it is handled by a device like a package rename, for example spamassassin3,
might be the way to go. I can imagine the hawks being concerned that this
might provide a temptation to avoid the hard work of backporting, but it
seems like a reasonable device to want to have in the armoury. Perhaps
some safeguard could exist. For example the archive team could treat such
a new package as they would a new candidate.
If that were so then perhaps 'for C/Python/Perl incompatibilities the maintainer
should consider (whatever that means!)' use of this device, whatever it is.
As far as the trade-off goes, the example you give 'work for avoiding it'
we also have 'critical to purpose', and I'm sure there are others. Not
everyone will regard such purposes as equal, so, as with APIs, there may
be some value in trying to enumerate them.
There again perhaps a more realistic model is agent-centred:
'maintainer decides'
I can't see the harm in pursuing both avenues at this stage.
Returning to 'reasons to rename', perhaps a safeguard could be some consensus
around what are reasonable trade-offs.
> >>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. :-)
Don't worry, just a momentary lapse into civility ;)
> >>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.
>
> Right.
I am under the impression that there was a time when a better case could
have been made that web-browser software was in an arms-race.
I'm slightly nervous about the single interest working criteria
'arms-race' or 'useless'. I imagine a big part of the bottom line for
whether a package should enter volatile, is whether such a relationship
would work. 'Would it work if package XYZ went into volatile ?'
But I suppose volatile needs more time to define itself, before
this question has its meaning. Its a bootstrap.
I have no particular interest in hardware drivers. But an observation
occurs to me.
Each individual driver goes through a lifecycle during which it is for
a time 'immature software' and then 'grows up'. As such, following the
logic above, it is not a good candidate. But, the great stream of drivers
is in some way like the typical volatile software: it is almost as if it
is battling with some co-evolving enemy (Indeed, in some cases it may be).
Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall
Reply to: