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

Bug#798762: Lintian tag pre-depends-directly-on-multiarch-support too much debhelper-centric



On Sat, Sep 12, 2015 at 05:13:46PM +0200, Niels Thykier wrote:
> We will look into a different wording (patches welcome).

Ok, this is is just a suggestion and it's probably not perfect, but at
least it does not blindly assume that the user is using debhelper.
diff --git a/checks/control-file.desc b/checks/control-file.desc
index 6c75014..6f3c72d 100644
--- a/checks/control-file.desc
+++ b/checks/control-file.desc
@@ -225,17 +225,15 @@ Tag: pre-depends-directly-on-multiarch-support
 Severity: important
 Certainty: possible
 Info: The control file mentions multiarch-support in a Pre-Depends line.
- Usually multiarch-support is inserted into Pre-Depends via ${misc:Pre-Depends}
- by dh_makeshlibs. In order to be able to remove the multiarch-support package
- from glibc without updating every package, Pre-Depends: ${misc:Pre-Depends}
- should be used instead. Then multiarch-support can be removed by a change
- in debhelper followed by a binNMU of all affected packages.
+ Packages using debhelper should not have a hardcoded Pre-Depends on
+ the multiarch-support package because ${misc:Pre-Depends} already takes
+ care of that (using debhelper 9). The idea is that a change in debhelper
+ followed by a mass binary-only rebuild of all affected packages would
+ remove this predependency for all packages quickly.
  .
- Please also ensure that source package at least build-depends on
- debhelper version 9 or above.
- .
- In order to ease the multiarch-support removal the severity of
- this tag is important.
+ Packages not using debhelper should not have a hardcoded Pre-Depends on
+ the multiarch-support package either, because a stable release has already
+ happened and it's now safe to drop the predependency.
 
 Tag: invalid-restriction-formula-in-build-profiles-field
 Severity: important

Reply to: