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

Re: Policy about debian/compat

Sven Mueller wrote:
> Also true, but as I frequently need to backport packages to (old)stable,
>  I would really like people only to increase the debhelper compat level
> if they really _use_ new features in the new level.
> While I backported packages to sarge during the etch release cycle, I
> frequently (i.e. I can't remember a package where it wasn't like this)
> all I needed to do to make a package compile cleanly on sarge was to
> decrease the compat level back to 4. So specifying 5 there was utterly
> useless in the first place. Just because debhelper supports a new compat
> level doesn't necessarily mean you should depend on that. Unless, of
> course, you actually rely on some effect of that new compat level during
> your build.

Debhelper sometimes has to defer bug fixes to new compatability levels,
since the bug fixes have the potential for breaking some packages in
edge cases, and thus should only be enabled when the maintainer is ready
to test for breakage. For example, v6 mode reverses the order of
maintainer script fragments in the prerm and postrm scripts, which fixes
bugs in some packages. However, reversing the order of chunks of the
scripts like this is a big change that could potentially break things. 
(#419060) Another example is dh_installdocs skipping empty files
starting in v5 mode.

I maintain debhelper and yet I am not always sure without excessive
analysis whether switching to a new compat mode will enable such a
change and improve a given package, or will be a no-op. The best way I've
found to take advantage of a new compatability mode is to switch all my
packages to it, even if the change is a no-op for many of them, and then
check the results, keeping in mind the list of changes that compatability
mode could have made.

I realise there's a tension here with backports, but 

a) backporting debhelper shouldn't be hard
b) I try to finish new compatability levels before[1] Debian releases so
   they are already available for backports by the time masses of
   packages use them. Stable supports v5 mode; oldstable supports v4 mode.

see shy jo

[1] Currently well before, since the release team likes to freeze
    debhelper with the toolchains. :-/

Attachment: signature.asc
Description: Digital signature

Reply to: