Dear debhelper maintainers,

For lintian-brush, it would be really useful if it was possible to discover
which patterns it would be installing, why and where.

I have no idea how hard this would be to implement, and whether this
information is readily available in debhelper - but figured it's at least worth
starting the discussion and seeing where it goes. I suspect there are some
corner cases where it's impossible to discover like where dh-exec is in use
(but even some information would be great).

I imagine something like a "dh_assistant installed-files" that then reports:

[
   {
      'install_path': '/usr/share/man/man1/blah.1',
      'tool': 'dh_installman',
      'tool_config': 'debian/blah.manpages',
      'source_path': 'debian/blah.1',
   },
   {
      'install_path': '/usr/bin/blah',
      'tool': 'dh_install',
      'source_path': 'scripts/blah',
   },
   {
      'install_path': '/usr/lib/*',
      'tool': 'dh_install',
      'source_path': 'debian/tmp/usr/lib/*',
   },
   ...
]

Jelmer Vernooij:

I can definitely see how that would be interesting to you.
Unfortunately, debhelper is a bunch of "black box" tools that knows
nothing about each other. Even figuring out which dh_tools will be run
is non-trivial (but I might be able to do that).

The best I can offer is a "post build" list of which tools installed
what where.  But I am pretty sure that would not be helpful to your case
(because that would be "did install" and not "would install").

Even if I did find a solution, it would rely on each tool "helping out"
somehow.  In other words, the solution would be incomplete or "unsafe"
with third party tools involved (or both).


Can you describe the use cases where you see the use for this?  Maybe we
can meet somewhere in the middle for them.

~Niels

Hi Jelmer,

I am still waiting/hoping for your feedback on this. :)

I would like to know what problem you want to solve using this data. :)
If we are going forward with this that information would be necessary to
understand what to do with:

 1) debhelper supported substitutions (should the be expanded or not)
    - If they are to be expanded, then when do we do when we cannot
      expand them?

 2) globs - currently debhelper is strict on expanding globs.  The
    provided example output implies it should *not* be expanded.

 3) search path - debhelper cannot know where in the search path a file
    is found unless the file is present (e.g., d/tmp is only available
    after dh_auto_install).

 4) executable config files.  This involves third-party tooling and is
    completely out of control for debhelper for how they will behave.

 5) do you want tools like dh_link to provide data? It does not
    "install" any upstream provided file but it can generate links.


I am still not sure to what extend debhelper can help with/provide this
data in its current form.  However, I would still like to know the
problem better so I can look into supporting it in the future.

Thanks,
~Niels

Hi Niels,

Part of the challenge here is that I'm still trying to figure out
exactly what we can do here as well.

Rather than talking specifics which requires a lot more thought, let
me at least provide you with the background to what I'm trying to do.

Some of the use cases I'm trying to support are:

 * updating filepatterns in debhelper files to adjust for upstream
   changes, e.g. dropping patterns when there are no longer any files
   being provided that match those patterns, or adding new entries

 * determining which files in a source tree are relevant for various
   fixers because they're installed by the packaging.
   e.g. we only need to fix .desktop files that are installed by
   the debian package, not just any .desktop files

 * fixing file installed into bad install locations

 * being able to detect when packaging changes impact file
   installation, e.g. side-effects from a debhelper 12 => 13 upgrade

 * e.g. generating a stub manpage where a manpage is not installed

 * e.g. splitting packages with a large number of arch-all files

The last two in particular are very speculative, but those are the
sorts of things I'm thinking about.

The janitor is best-effort - it's fine if we can do the analysis for
some packages, and have to skip other packages because they e.g. rely
on executable config files - so long as we know that we have to skip a
package.