Control: tags -1 wontfix

On Fri, 16 Aug 2019 09:45:52 +0100 Simon McVittie <s...@debian.org> wrote:
> Package: debhelper
> Version: 12.4
> Severity: wishlist
> 
> [...]
> 
> Some participants in a recent thread on -devel assert that this is too
> strong, either for GSettings schemas associated with libraries or for all
> GSettings schemas, and should be a Recommends or even a Suggests. Without
> taking a position on the correct balance between "weaken non-essential
> Depends to Recommends to make the system more flexible" and "don't
> lose user configuration", this is not currently possible, because
> dh_installgsettings always generates a hard dependency.
>

Hi Simon,

I am impressed that you went the extra mile here - but with the patch
and the follow up analysis.  I honestly do not think it was to be
expected of you to do any of this given you are not invested in the
change at all. As long as you find it fun and interesting to do these
things, then by all means. But if you ever feel burdened by it, I hope
you will remember that you can say no and leave it to the people wanting
the change.

As you have probably noticed, I tagged this wontfix because it is not
clear to me that there is consensus that this is necessary (which
Raphael Hertzog also suggested[1]).

However, I have been stealing most of the test case you provided.

 \o/  Thanks for improving debhelper by increasing test coverage! \o/

That said, I have not reviewed the rest of the patch.

> [...]
> 

Finally, a look at your analysis in case this gets reopened.

> Looking at the other dh scripts for other mentions of misc:Depends:
> 
> * dh_gconf is in the same situation as dh_installgsettings, but GConf is
>   obsolete anyway, and nobody seems to have objected to the dependency
>   in the 15 years since it was added, so I think that one can be ignored.
> 

Indeed, dh_gconf will be history soon and will not matter.

> * dh_installcatalogs adds a dependency on sgml-base, so that its triggers
>   will be run. Is this essential to the functionality of SGML stuff or
>   could a maintainer have valid reasons to weaken it?
> 

I doubt it will be a concern.  The package (sgml-base) is small and due
to its await trigger it has very strict limitations on what it can
depend on.  Also, without the triggers, some catalog lookups allegedly
breaks horribly.

> * dh_installdebconf adds a dependency on a debconf implementation, but the
>   man page only says it "probably" needs to depend on debconf, so perhaps
>   this one should be possible to weaken?
> 

In theory, yes.  In practise, the point of shipping debconf templates is
to use them via debconf in maintscripts (or .config script).  I think it
warrants a separate discussion before considering to add this.

> * dh_installdocs adds a dependency on the package with linked documentation,
>   which Policy ยง12.5 says has to be a hard dependency, so this is correct.
> 
> * dh_installinit and dh_installsystemduser add a versioned dependency on
>   init-system-helpers, which is used from maintainer scripts (so it's
>   correct to be a hard dependency) and is Essential anyway.
> 


Agreed for those. :)


> * dh_installxfonts adds a dependency on xfonts-utils, again for the
>   maintainer script. This is guarded by `which` so maybe it should be
>   possible to weaken? (I don't know.)
> 

Not sure to be honest.  But most of the packages that would trigger the
condition literally contain "xfont" or "x11" in their package name, so I
am not overly concerned about this being an issue.  And the first
solution to consider would probably be to convert it to a trigger if at
all possible.

> * dh_ucf unconditionally uses ucf in the maintainer scripts, so a hard
>   dependency is certainly correct.
> 
> Regards,
>     smcv

Agreed.

Thanks,
~Niels


[1] https://lists.debian.org/debian-devel/2019/08/msg00349.html

Reply via email to