On Sun, Aug 15, 2010 at 13:19:19 (CEST), Jonas Smedegaard wrote:
> On Sun, Aug 15, 2010 at 09:16:26AM +0200, Reinhard Tartler wrote:
>>On Sun, Aug 15, 2010 at 02:23:59 (CEST), Felipe Sateler wrote:
>>> On 14/08/10 11:08, Reinhard Tartler wrote:
>>>> On Sat, Aug 14, 2010 at 16:19:27 (CEST), Felipe Sateler wrote:
>>>>> On 14/08/10 06:13, Reinhard Tartler wrote:
>>>>>> debhelper maintains a history of very stable interfaces, called
>>>>>> compat levels. I'd really love to see something similar to
>>>>>> cdbs. And this very strict commitment to stable interfaces and
>>>>>> semantics help a lot for backporting packages.
>>>>> How does maintaining several API versions (compat levels) help
>>>> You can pretty much rely on the exact behavior of debhelper
>>>> commands. future improvements and addition are still possible at
>>>> higher levels, but for the sake of compatibility, they are not used
>>>> until you bump the debhelper compat level.
>>> But that is forward-porting, not backporting.
>> if you always use the most recent debhelper compat level, then yes. If
>> you leave your package at the highest compat level that is in the
>> oldest release you care about, then it helps backporting.
>> for stable this would mean to avoid the short form 'dh' forms with the
>> quilt series features.
> Do I understand you correctly here in that you really are not talking
> about the ABI levels at all, but minor version numbers of debhelper?
What's an "ABI" level?
ABI (== application binary interface) in general means something
completely different than we are discussing here.
> Or do you suggest to stick to debhelper compat level 6 for now, to not
> accidentally use features introduced in e.g. 7.2?
stable ships debhelper version 7.0.15, I don't think we'd need to
support any version earlier than that.
Just curious, what features have been introduced in 7.2?
> Or do you somehow mean to say that the fine ABI handling of debhelper
> also cover the changes between 7.0 and 7.2?
Jonas, please avoid the term ABI in the context of debhelper. I had to
read your question 3 times and still don't get it. Let me explain why:
"ABI" is often called the (Machine) Application Binary Interface. This
is what the processor manufacturer defines how various details how
applications, functions, syscalls, etc. work on *assembly* level.
What we in terms of packaging often discuss is the *library* ABI, which
again means something completely different (and has IMO a pretty
unfortunate name) . The *library* ABI is broken iff an updated version
of a library breaks the externally visible behavior of previously
So if you consider debhelper as a library for makefiles, then we could
of course discuss the stability of interfaces. So if we consider
backporting packages to stable releases as a goal that we should aim for
(and I think we should), then yes, I think we should avoid features that
are not found in debian/stable. Demanding for more is IMO not worth the
effort, but I won't certainly stop anyone from stepping up to make a
package build in oldstable as well.
Reinhard Tartler, KeyID 945348A4
pkg-multimedia-maintainers mailing list