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 >>>>> backporting? >>>> >>>> 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 existing interfaces. 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. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers