[debhelper-devel] Bug#415396: Bug#415396: "dh_install --list-missing" should ignore manpages and other installed files

[Niels Thykier]

Michael Stapelberg:
> On Sun, Mar 26, 2017 at 2:54 PM, Niels Thykier <niels at thykier.net> wrote:
> 
>> [...]
>>
>> Remarks:
>>
>>  * For backwards compatibility, dh_install still has to do what it is
>>    currently doing in compat 10 (or earlier).  Possibly by calling
>>    dh_missing; possibly by keeping the existing code for now and only
>>    using it in compat 10 or earlier.  Whichever works.
>>    - reason: Otherwise we break people's expectations when they have
>>      called dh_install --(list|fail)-missing.
>>
> 
> Done.
> 

Thanks. :)

> 
>>
>>  * log_installed_files - what is the rationale behind doing a file
>>    per helper?  It is fine if there is one, but if not, I would prefer
>>    to keep things simple and just have one file.
>>    - bonus side effect: Multiple calls inside the same helper would
>>      become additive, which is probably better suited for how most
>>      helpers work right now.
>>
> 
> The rationale was to make debugging easier, and encourage future
> parallelization of individual helpers (not sure if that’s planned at all).
> I don’t have strong feelings about this, so let me know if it should be
> changed (or go ahead and change it).
> 

The debhelper sequencer is not really geared towards parallelization.
This is inherent in many of the choices made (e.g. the "log" files).

> 
>>
>>  * Open question: Should we run dh_missing by default in "complain"
>>    mode and then migrate to "fail mode" by default in a later compat
>>    level
>>
> 
> I think running it in complain mode once the remaining helpers were updated
> makes sense. Before that, the false positives might annoy people more than
> doing any good.
> 

It begins: #858834 :)

> Migrating to fail mode is a separate beast altogether. We should gather
> some data on how many packages would need to be updated due to such a
> change before seriously considering it, I think.
> 

True, but it would be at least 2 compat levels way - specially
considering that third-party tools need to be updated.

> 
>>
>> Beyond that, I am happy to merge it as a WIP thing.
>>
> 
> Great. Find attached an updated patch including documentation.
> 

Thanks.  I am a bit busy this week, so odds are I will not have time to
look at it until the weekend at the earliest.  Please ping me if you
have not heard from me on this by Tuesday.

If you got time to spare and want to keep things moving, I got some
things I am considering to change:

 * Make log_installed_files use "basename($0)" rather than taking an
   argument for the "helper name".  The actual file name is an
   implementation-detail anyway, and tool writers do not benefit from
   the addition complexity

 * Make log_installed_files support being called multiple times from
   the same helper to make it easier for tool writers.  Most of them
   probably don't need to accumulate their set of installed/processed
   files.  dh_install basically only does it because it was implementing
   the "missing" feature AFAICT.

If you want to start on dh_installman (or other tools):

 * CAVEAT: The tools have to start acting on *all* packages but
   "do nothing" for "uninteresting packages" like dh_install does.
   Otherwise, the user will see "missing" entries when doing an
   dpkg-buildpackage -B build (or -A).

The debhelper API here is probably horribly lacking IRT making this
easy.  So far, it has only been done in dh_install, but it is a
necessity for this feature to work correctly (Especially with
--fail-missing).  Bonus points for improving that. :)

> Is there any large-scale testing that debhelper has, to confirm that my
> change doesn’t break things so far?
> 

No.  But I suppose we could do an upload to experimental and ask if
Lucas have time to do a mass-rebuild.

~Niels