[debhelper-devel] Bug#895061: exclusions and dh_missing

[Niels Thykier]

Nicolas Boulenguez:
> Package: debhelper
> Version: 11.1.6
> Severity: wishlist
> 
> Hi.
> 

Hi, :)

> Some debhelper commands log some files as installed while they are not,
> so that dh_missing does not report them later.
> * files missing because of nodocs
> * files ignored because the package is not selected (-p/-N/-a/-i or similar)
> 
> Should excluded files also be marked as installed?
> (for example, dh_installexamples does so)

To clarify the "true" purpose of the "installed-by" logs:

They are intended to make the integration between dh_install* and
dh_missing "just work(tm)" for people (in the average case).

This is complicated by things like builds with dpkg-buildpackage
-A/-B/-b or builds with various profiles enabled, where the set of
packages are not always the same.  Not to mention that sometimes people
call the same helper multiple times with only some arguments and expect
everything to work, etc.

What should be logged?  The files and folders necessary for dh_missing
to not incorrectly complain when you use dh_missing
--(list|fail)-missing and build with any variation of "dpkg-buildpackage
-A/-B/-b plus build profiles".

I have ignored --exclude and just logged files:

 1) It is easier + faster
 2) If people have excluded it, they have actively considered the file
    and probably know what they are doing.

It is true that they could have have excluded it because they wanted to
install it in a separate call but forgot.  So far that has not been a
problem.  Note that one of things that people use dh_missing for is to
detect when upstream provides new files or renamed something.

> The selected behaviour should probably be explicit in the --exclude
> section of debhelper(7).
> 

Certainly.

> Please allow me to suggest a third way: reserve --exclude for
> overrides of hardcoded lists, but ignore this option for explicit user
> selections.
> 

Note that if you by "user selection" mean e.g. command line arguments or
patterns in the config file, then that is exactly what --exclude was for.

Whereas --ignore is useful for ignoring a "config file" in debian.


> For example, --exclude is useful to prevent dh_compress acting on a
> specific file, or dh_installdocs acting on a specific
> debian/changelog,

Note: The dh_installdocs example should have been dh_installchangelogs
and should be using --ignore and not --exclude.  (And in the concrete
case, --ignore cannot used for that file as dh_installchangelogs insists
on having a Debian changelog).

> but "dh_installexamples --exclude=foo/bar foo" can
> be avoided with a more specific pattern.
> 

I think I might need a bit more here.  I do not see what the problem is
with using "--exclude foo/bar foo".  You could have:

  foo/bar/...
  foo/baz
  foo/baz/bar
  foo/baz/baz
  foo/foobar
  foo/...

In that case, --exclude foo/bar would only exclude the first item (i.e.
the directory and everything beneath it) but not foo/baz/bar.

> Even if the caller ends up generating a list, the result will probably
> be more maintainable that black magic inside the dh_ tool.
> See dh_installexamples for an example of the complexity added by --exclude.
> 

The complexity of dh_installexamples (and similar commands) is related
to the ability to exclude folders while still being somewhat efficient
at copying over the files (doing a copy per file is expensive).
  Some of that could be handled by refactoring the (almost) same code in
the helpers using that pattern and move it into Dh_Lib.

Thanks,
~Niels