Re: Getting dh_install to do what we need
Joey Hess <joeyh@debian.org> writes:
> Gergely Nagy wrote:
>> At the moment, I have something that works like this:
>>
>> ,----
>> | #! /usr/bin/dh-exec-install
>> | # The next one will simply echo it back to dh_install
>> | source-file /dest-dir/
>> |
>> | # This one will copy the file itself, following similar heuristics as
>> | # dh_install: it will first try the source file directly, and if it's
>> | # not found, try the same path under debian/tmp/. The destination is
>> | # relative to debian/${PACKAGE} (as per dh compat level 7+)
>> | #
>> | # Since dh-exec-install does the copying itself, this line is NOT
>> | # echoed back to dh_install.
>> | source-file /dest-dir/new-name
>> `----
>
> Of course the reason I didn't add this to dh_install 10 years ago is
> that this syntax sucks. It's really horrible; either the trailing slashes
> are much more significant than makes sense, or what it does depends on
> the state of the filesystem(ie, checking whether /dest-dir/new-name is
> a directory).
I disagree that it is horrible. Yes, trailing slashes become much more
significant. But that is already common behaviour for tools like cp,
scp, rsync, ... And having to rename outside of dh_install or replacing
dh_install completly is usualy worse.
>> My implementation copies the file to the desired destination, which may
>> or may not be a good idea - I'll do some more tests to see which one's
>> less painful and more safe.
>
> That breaks -X, --fail-missing, --list-missing, --sourcedir, and --tmpdir
That is part of what I fear will happen with executable config files.
How do you get access to the parameters passed to dh_*? Scripts my need
to honor them.
MfG
Goswin
Reply to: