Hi Niels, On Sun, Oct 24, 2021 at 10:12:13AM +0200, Niels Thykier wrote: > On Sat, 25 Sep 2021 22:09:53 +0200 Niels Thykier <ni...@thykier.net> wrote: > > Control: tags -1 moreinfo > > > > Jelmer Vernooij: > > > Package: debhelper > > > Version: 13.5.2 > > > Severity: wishlist > > > > > > 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: > > > > > > [...] > > > > 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 > 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.
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. -- Jelmer Vernooij <jel...@jelmer.uk> PGP Key: https://www.jelmer.uk/D729A457.asc
