Backporting hooks

[Kilian Krause]

Tzafrir,

On Tue, Nov 21, 2006 at 02:53:55PM +0200, Tzafrir Cohen wrote:
[...]
> I noticed you have not changed the compatibility level or even standards
> version.

Well, yes where it was not needed. For example pwlib does do the altered
compat level switching. What I actually wondered about was the commit in
zaptel which was obviously copied over to sarge without violently
breaking anything clear at hand. As I haven't done functional tests it
might be needed to extend the backporting for the dh_makeinstallmodules
call back to the old version and make this entire block cleanly depend
on DH_COMPAT like pwlib.


> One related issue:
> 
> I'm trying to merge the s/.dfsg/~dfsg/ change into my Sarge package and
> get tons of Lintian messages of the sort of:
> 
> E: asterisk source: bad-version-number 1:1.2.13~dfsg-1
> 
> I have some 15 messages in various packages. Any way to suppress them
> all in one cetral place rather than adding a lintian overrides file for
> every package?

looks like this calls for scripting the forced 4 byte version numbers
into the backports hook. That way 1:1.2.13~dfsg would become
1:1.2.13.0.dfsg or so.. Optionally this should be accompanied by a
decrement of some kind for the debian version. Yet, as there are no
current "official" sarge packages of asterisk for these versions we
probably just need to "fix" the 3-4 byte version number and should be
fine. 

Single remaining issue then would be the broken upgrade to Etch packages
of the same archive. That would only work if the 4th digit and debian
version are properly decremented. If you see any clean way of
implementing this mechanism and still allow upgrades to Etch/Sid, please
propose it and I'll help you with the needed scripting.

-- 
Best regards,
Kilian