Your message dated Sat, 18 Jul 2020 10:12:19 +0300
with message-id <[email protected]>
and subject line Re: Bug#965185: dh_install --sourcedir file tries to install
everything but file
has caused the Debian Bug report #965185,
regarding dh_install --sourcedir file tries to install everything but file
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
965185: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965185
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: debhelper
Version: 13.1
Severity: important
since some version after buster, the following command:
dh_install -pfoo --sourcedir=bar usr/bin/foo
does not work anymore, instead of working on a single file
specified on the comand line, it tries to work on whole
d/foo.install.
Interestingly enough, omiting --sourcedir fixes this
(provided it can find the file).
In buster and before it worked just fine, now some of
my packages FTBFS due to this.
Thanks,
/mjt
--- End Message ---
--- Begin Message ---
Ok, I see where it comes from.
Since dh_install also looks at . as sourcedir, and
there are some files in d/*.install which mentions
path relative to the source dir (not debian/tmp),
by restricting dh_install's search path just to d/tmp
makes it unable to find files starting from the build
tree. Hence it complains. Without --sourcedir it
searches in both d/tmp and ., so finds everything.
In buster version of my packages I only used d/tmp
for all files, later on I added some files which
are left in the build tree, not installed by the
upstream build system, - so dh_install actually
needs to check . too, not only d/tmp, -- hence my
confusion.
Closing this bugreport now, it is definitely invalid
having in mind that this is a well-known dh_install
behavor.
In my d/rules, at the same time, I replaced dh_install
invocations with either mkdir+mv pair or with plain
install(1), to avoid similar issues in the future.
Yes this way is longer and less readable, but it is
definitely less error-prone and more native, so to
say, - it does what people think it should do, unlike
dh_install which does some non-obvious things too.. :)
Thanks,
/mjt
--- End Message ---
