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

[Michael Stapelberg]

On Mon, Apr 3, 2017 at 1:07 PM, Niels Thykier <niels at thykier.net> wrote:

> Niels Thykier:
> > Michael Stapelberg:
> >> On Sun, Mar 26, 2017 at 2:54 PM, Niels Thykier <niels at thykier.net>
> wrote:
> >>
> >> [...]
> >>
> >> 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.
> >
>
> Created a branch for it:
>
> https://anonscm.debian.org/git/debhelper/debhelper.git/
> log/?h=bug-415396-dh_missing


Thanks a lot!

In turn, I created a branch in the freeradius packaging:
https://anonscm.debian.org/cgit/pkg-freeradius/freeradius.git/log/?h=dh_missing

Maybe I did the wrong changes (?), but when building, I get an error:

$ dpkg-buildpackage -b
[…]
dh_missing: etc/freeradius/3.0/mods-available/pam exists in debian/tmp but
is not installed to anywhere
dh_missing: etc/freeradius/3.0/mods-available/sradutmp exists in debian/tmp
but is not installed to anywhere
dh_missing: etc/freeradius/3.0/mods-available/idn exists in debian/tmp but
is not installed to anywhere
dh_missing: etc/freeradius/3.0/mods-available/ntlm_auth exists in
debian/tmp but is not installed to anywhere
The following debhelper tools have reported what they installed
* dh_installman
If the missing files are installed by another tool, please file a bug
against it
For a short-term work-around: Add the files to debian/not-installed
dh_missing: missing files, aborting
debian/rules:41: recipe for target 'override_dh_missing' failed
make[1]: *** [override_dh_missing] Error 255
make[1]: Leaving directory '/home/michael/d/pkg/freeradius'
debian/rules:86: recipe for target 'binary' failed
make: *** [binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit
status 2
dpkg-buildpackage -b  60,34s user 7,70s system 165% cpu 41,147 total

Can you reproduce the issue?



>
>
> Review welcome.  Note that the "installed-by" files work differently
> than documented.  I have opted for keeping the behaviour and correcting
> the documentation.
>
> > 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
> >
>
> Done.
>
> >  * 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.
> >
>
> Done.  This will probably come in handby due to the next item and the
> following call pattern.
>
>  dh_install -ppkg foo bar
>  dh_install --remaining
>
> > 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).
> >
>
>
> Did a prototype for dh_installman, which seems to be working (with the
> above CAVEAT)
>
> NB: Due to how this is implemented, the "install-by" files will get
> duplicates when you do:
>
>   dh_install -a # first copy
>   dh_install -i # second copy
>
> It does not appear to be a problem atm., so I have left it at that.
>
> > 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. :)
> >
>
> Still lacking.
>
> >> 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
> >
>
> I might do the upload "soon" (before the release), but lets keep the
> mass-rebuild for post-freeze to avoid diverting peoples attention.
>
> Thanks,
> ~Niels
>
>
>


-- 
Best regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debhelper-devel/attachments/20170407/65c50613/attachment-0002.html>