Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#901715: debhelper: dh_install unexpected behaviour when ".install" file has an executable bit
236 views
Skip to first unread message
nadavr
Jun 17, 2018, 6:20:03 AM6/17/18
to
Package: debhelper
Version: 10.2.5
Severity: normal
Dear Maintainer,
dh_install tries to run files listed in my ".install" file instead of adding them when the ".install" file has executable permissions.
This also results in errors when listed files prompt errors in the default shell interperter (why wouldn't they?).
Once the executable bit is gone, everything works fine.
I don't see any reason for this to happen, and no documentation. If there is a reason, I request it be properly documented so this pitfall can be avoided.
This behaviour was first encountered on Ubuntu 18.04 before I replicated it on Debian, because, and forgive me if I'm wrong, Ubuntu uses sources
from Debian.
Small note: This is especially frustrating because my development is on WSL and I cannot make mounted metadata work, forcing me to copy my sources.
-- System Information:
Debian Release: 9.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.87-linuxkit-aufs (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages debhelper depends on:
ii autotools-dev 20161112.1
ii binutils 2.28-5
ii dh-autoreconf 14
ii dh-strip-nondeterminism 0.034-1
ii dpkg 1.18.24
ii dpkg-dev 1.18.24
ii file 1:5.30-1+deb9u1
ii libdpkg-perl 1.18.24
ii man-db 2.7.6.1-2
ii perl 5.24.1-3+deb9u4
ii po-debconf 1.0.20
debhelper recommends no packages.
Versions of packages debhelper suggests:
pn dh-make <none>
-- no debconf information
Version: 10.2.5
Severity: normal
Dear Maintainer,
dh_install tries to run files listed in my ".install" file instead of adding them when the ".install" file has executable permissions.
This also results in errors when listed files prompt errors in the default shell interperter (why wouldn't they?).
Once the executable bit is gone, everything works fine.
I don't see any reason for this to happen, and no documentation. If there is a reason, I request it be properly documented so this pitfall can be avoided.
This behaviour was first encountered on Ubuntu 18.04 before I replicated it on Debian, because, and forgive me if I'm wrong, Ubuntu uses sources
from Debian.
Small note: This is especially frustrating because my development is on WSL and I cannot make mounted metadata work, forcing me to copy my sources.
-- System Information:
Debian Release: 9.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.87-linuxkit-aufs (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages debhelper depends on:
ii autotools-dev 20161112.1
ii binutils 2.28-5
ii dh-autoreconf 14
ii dh-strip-nondeterminism 0.034-1
ii dpkg 1.18.24
ii dpkg-dev 1.18.24
ii file 1:5.30-1+deb9u1
ii libdpkg-perl 1.18.24
ii man-db 2.7.6.1-2
ii perl 5.24.1-3+deb9u4
ii po-debconf 1.0.20
debhelper recommends no packages.
Versions of packages debhelper suggests:
pn dh-make <none>
-- no debconf information
gregor herrmann
Jun 17, 2018, 9:00:02 AM6/17/18
to
On Sun, 17 Jun 2018 10:10:21 +0000, nadavr wrote:
> dh_install tries to run files listed in my ".install" file instead
> of adding them when the ".install" file has executable permissions.
> This also results in errors when listed files prompt errors in the
> default shell interperter (why wouldn't they?).
> Once the executable bit is gone, everything works fine.
> I don't see any reason for this to happen, and no documentation.
It's on purpose, and it's documented in debhelper(7):
> dh_install tries to run files listed in my ".install" file instead
> of adding them when the ".install" file has executable permissions.
> This also results in errors when listed files prompt errors in the
> default shell interperter (why wouldn't they?).
> Once the executable bit is gone, everything works fine.
> I don't see any reason for this to happen, and no documentation.
DEBHELPER CONFIG FILES
Many debhelper commands make use of files in debian/ to
control what they do. Besides the common debian/changelog and
debian/control, which are in all packages, not just those
using debhelper, some additional files can be used to
configure the behavior of specific debhelper commands. These
files are typically named debian/package.foo (where package of
course, is replaced with the package that is being acted on).
…
The syntax of these files is intentionally kept very simple to
make them easy to read, understand, and modify. If you prefer
power and complexity, you can make the file executable, and
write a program that outputs whatever content is appropriate
for a given situation. When you do so, the output is not
further processed to expand wildcards or strip comments.
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- NP: Las Primas: Bombon Chocolata
Nadav Ruskin
Jun 17, 2018, 9:30:03 AM6/17/18
to
Thank you for the quick and concise reply. I was looking at DH_INSTALL(1) instead. Why is the documentation split between the two files? Also, looking back at DH_INSTALL(1) I see a line that appears to be contradicting the documentation in debhelper(7):
> dh_install cannot rename files or directories, it can only install them with the names they already have into wherever you want in the package build tree.
> However, renaming can be achieved by using dh-exec with compatibility level 9 or later. An example debian/ package.install file using dh-exec could look like:
> #!/usr/bin/dh-exec
> debian/default.conf => /etc/my-package/start.conf
> Please remember the following three things:
> •
> The package must be using compatibility level 9 or later (see debhelper(7))
> •
> The package will need a build-dependency on dh-exec.
> •
> The install file must be marked as executable.
This requires the ".install" file to be both an executable and have a simple syntax. Here's another question, is there documentation to how these executable install scripts are supposed to look? I wouldn't know where to start.
In any way, I find the documentation to be lacking. There should be a big red flag on setting the ".install" file as an executable. I was not able to find the answer to my woes in online or offline resources for days of work. An error message saying "Are you sure foo.install is meant to be run as an executable"? would be nice, however if such practice is frowned upon a notice that is more than a side note in the docs will make a big difference. Making Debian packages should be a friendly process, I'm the first person in my company to even try making one, with some people here having over ten years of experience with Linux, and it's exactly opaque errors like this that prevent people from using this essential feature in software development.
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlsmV99fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZ1Hg/7B7HYqlVzfC3wkVSYQxzoMD4yE4cFJrsRd3q9xMVp87iXLPLhrAGROBJx
tHy8If2Lk6gmJFy23kCF3iz5S/smTv5YHxelJQBzsI3kb6Pe+3pyvPbkFRehW20t
A9G8Oe1OmJwVKGhElA22bpsUIjZSniRsQAc01NXj+xDV79gUCeT4Iav+NkdfqKF8
aCmLunRf4OZ31XiiOv9izRUDfN89LpFUUKQ+JJSH2ouDA7j0rYPRYD2MTShd/SOH
pD6/zIf/OP8d6tMcsJtFr6Q/Xl+gVOZcVMC6zKVZq28N+P4F1a/cZ2BhKlHgTDr2
XrFPOybsAVaDLO+zV+8m2TSi0KNFvq4XwTnEPDdIZn/Y2PQHbwlWxlvBFUjYuifx
wXouNv57meTzllM8uojuaQ/oz+IFRfROQ5D0rNF9oMtw78SXKmlZqd8hi9s10nUP
i0qpGEBarmIROC4Pdx+xPmuFl5o4Tg3Jp3QsFSivfC6P/M+/HGyRf8ylU6aNl35H
X931yx92d3mt2S6XeqiGyVNVP4xBqh6CBATjm4zKJOKNCFy1V1EkJLmq/RcLpdaZ
H0Rcad++fJT3ZSyMqOwMKp8RQxgPOF1Vr4Mvjhxdmf+EU8wT3p+S+a2C5gkH6iai
fM8fXc4bXhMCWQ/wOLIQRSfw35h8P0ksb8QxQaOlPocfuotOOE0=
=HsoX
-----END PGP SIGNATURE-----
Regards,
Nadav Ruskin
Mattia Rizzolo
Jun 17, 2018, 10:10:02 AM6/17/18
to
On Sun, Jun 17, 2018 at 04:20:09PM +0300, Nadav Ruskin wrote:
> Thank you for the quick and concise reply. I was looking at DH_INSTALL(1)
> instead. Why is the documentation split between the two files?
Because it's not "split between two files": the details in debhelper(7)
> Thank you for the quick and concise reply. I was looking at DH_INSTALL(1)
> instead. Why is the documentation split between the two files?
are about *all* the dh_* commands, not just dh_install.
There is an open bug about having some details like this one shared
between all the dh_* manpages, but the debhelper maintainer of course
wants to avoid having the documentation duplicated amongst dozens of
files.
> Also,
> looking back at DH_INSTALL(1) I see a line that appears to be contradicting
> the documentation in debhelper(7):
>
> > dh_install cannot rename files or directories, it can only install them
> > with the names they already have into wherever you want in the package
> > build tree.
> > However, renaming can be achieved by using dh-exec with compatibility
> > level 9 or later. An example debian/ package.install file using dh-exec
> > could look like:
> > #!/usr/bin/dh-exec
> > debian/default.conf => /etc/my-package/start.conf
> > Please remember the following three things:
> > •
> > The package must be using compatibility level 9 or later (see
> > debhelper(7))
> > •
> > The package will need a build-dependency on dh-exec.
> > •
> > The install file must be marked as executable.
>
> This requires the ".install" file to be both an executable and have a
> simple syntax. Here's another question, is there documentation to how these
> executable install scripts are supposed to look? I wouldn't know where to
> start.
config file" feature.
And what of the documentation in debhelper(7) is not clear enough of how
the executable install scripts should "look"? (which is probably the
wrong question, as debhelper obviously doesn't care about their look,
rather their output).
> In any way, I find the documentation to be lacking. There should be a big
> red flag on setting the ".install" file as an executable. I was not able to
> find the answer to my woes in online or offline resources for days of work.
> An error message saying "Are you sure foo.install is meant to be run as an
> executable"? would be nice,
If you are hitting issues like this, I recommend you ask for support on
the IRC channel #packaging on OFTC, there you could have had this answer
in few minutes (if you are lucky somebody is online in that moment,
which usually is the case) :)
> however if such practice is frowned upon a
> notice that is more than a side note in the docs will make a big
> difference.
As a matter of fact, it's often a detail considered hard to imagine,
because nobody creates executable files by mistake...
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Nadav Ruskin
Jun 17, 2018, 10:40:03 AM6/17/18
to
>
Because it's not "split between two files": the details in debhelper(7)
I see, fair point, count me as one of the users who could use this information in
DH_INSTALL(1) though. I don't think any common user needs to become an expert on the internals of debhelper to get a simple package going, so I'd advocate for pitfalls be listed on all man pages. It took me a while to understand all these tools are even linked.
>
How is this contradicting? It's one possible use of the "executable config file" feature.
Oh, I understand now. "
#!/usr/bin/dh-exec" makes it be processed by some interpreter other than bash, I didn't understand why it would have non-bash syntax. You're right, it's not contradicting.
>
And what of the documentation in debhelper(7) is not clear enough of how the executable install scripts should "look"?
You're right, I meant output. It doesn't say how the install mechanism works, I don't know what sort of commands I'd need to use to manually copy files to my Debian package and how to instruct "dpkg" where to install it. I don't see any reference for further reading.
Like I said, I'm developing on WSL on a mounted drive and can't get metadata working on it. Of course you might say that having no control over permissions can cause issues on multiple user cases over development and you'd be right, but allowing users to know what they'd done wrong is still important. Working on WSL is quickly becoming common practice, so I wouldn't call it a corner case. I have seen at least two StackOverflow cases that I'm positive were stuck with the exact same problem I had, and didn't have an answer.
>
If you are hitting issues like this, I recommend you ask for support on the IRC channel #packaging on OFTC
Thanks for the advice, I wasn't aware of that channel. I asked on #debian and got nothing.
> At which point would you emit said error?
Well, the only solution I can think of is outputting a warning whenever an executable fails to parse.
>
It's not frowned upon, why would it?
Because it requires setting a specific warning message to a specific tool, which also makes assumptions on your usage. Like I said I'm all for it, but others might not like the idea of "are you sure you meant for foo.install to be an executable?" appear every time their ".install" file, which they meant to be an executable, doesn't work.
I'd like to clarify that the documentation I counted on most was in https://www.debian.org/doc/manuals/maint-guide/dother.en.html#maintscripts . For a layman such as myself, this documentation clearly states that ".install" files are a special config file with its own simple language and nothing more. In fact, while searching the internet, people seemed surprised when they saw ".install" files trying to execute listed files. https://askubuntu.com/questions/982078/install-non-executable-files-with-dh-install/1047319#1047319
So I'd say I'm not the only one confused. In my opinion
DH_INSTALL(1), and
dother.en.html (being after all part of the official Debian documentation) need to be more clear about the fact ".install" files will be read as executables if possible.
Now that I think about it and understanding the "
#!/usr/bin/dh-exec" example, I think I have an even better idea: include an example that shows making the file an executable script that uses whatever the default interpreter ".script" files usually use. Surely there is one, right? and it could solve my WSL problem too, by making ".install" files with an executable bit be written with the simple default syntax.
--
Regards,
Nadav Ruskin
gregor herrmann
Jun 17, 2018, 12:50:03 PM6/17/18
to
On Sun, 17 Jun 2018 17:28:06 +0300, Nadav Ruskin wrote:
> > And what of the documentation in debhelper(7) is not clear enough of how the
> > executable install scripts should "look"?
> You're right, I meant output. It doesn't say how the install mechanism
> works, I don't know what sort of commands I'd need to use to manually copy
> files to my Debian package and how to instruct "dpkg" where to install it.
> I don't see any reference for further reading.
Both dh_install(1) and the page you mentioned:
> > And what of the documentation in debhelper(7) is not clear enough of how the
> > executable install scripts should "look"?
> You're right, I meant output. It doesn't say how the install mechanism
> works, I don't know what sort of commands I'd need to use to manually copy
> files to my Debian package and how to instruct "dpkg" where to install it.
> I don't see any reference for further reading.
https://www.debian.org/doc/manuals/maint-guide/dother.en.html#install
explain that a (non-executable) debian/package.install file looks
like
src/bar usr/bin
which means that the file bar from the directory src/ will get
installed into the directory usr/bin in the package.
Now the only difference with an executable debian/package.install is
that the same contents isn't written staticially but is the output of
the script. E.g. to achieve the same, debian/package.install could
say:
#!/bin/sh
echo "src/bar usr/bin"
which would be a bit stupid but should work that way :)
The real power and purpose of executable debhelper helper files is to
calculate paths at build time, e.g. depending on the architecture.
A reallife example from the perl world:
% cat libtext-bibtex-perl/debian/libtext-bibtex-perl.install
#!/usr/bin/perl -w
use Config;
# expand the perl binary module directory at build time
print substr($Config{vendorarch}, 1) . "\n";
print <<EOF
usr/share/man/man3/*.3pm
EOF
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
Nadav Ruskin
Jun 18, 2018, 2:40:03 AM6/18/18
to
I see! I understand now, thanks to your explanation. I can use your "stupid" script as a small hack to move development back to WSL. Thanks!
I showed the documentation to a few of my colleagues and none of them could make use of it. It is not intuitive to any of us to expect a configuration file to be replaceable with an executable that echoes back configurations. Is this common practice in Linux? I highly recommend a simple explanation like the one you just said is added to the documentation.
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlsmkCpfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZWJBAAqWE/6uxJYu2lxQd+xbPYCj/Xc65M+th5JJpE+xxpgii1gd/hNjvN+8n5
JCBarEkrvGB6DJgzGz0F+yt8opygctSZv9eK4JkM5ioMxEfIznqv22auSRalNK/w
xzAtaRdLScXjiTaKE6sV/9PrES6VL1r4Q/Op+eICQgkguRZ4cXZXFjCEFZSKuxh2
p1DjgGToIsLkFjIzEQ9KEBpJpYXTdWHjJInlPtCk4qaSQZumjFUuiZCLnTLXsbf5
32shVh+r9qhgLWovSn1p0Ccc/rgHb1iRwb9l4vYvSzVZgKlA9ubos5dlVBSdEYRM
nQJ1ezqQpNQhBbaWAumnpg/ptzBNyJP3L/qxJRvXOew9mgNoNqTMEhRLsQs5qU4c
CU7ya5t9YiYkqQAE2uSWAgfrK04x8C7IFgQP7FZ/+l+VEMosVVkow8WWdA+yrRhY
MW7JOSGUVwIwwydM5R6BX8yzJAnx3fuqJ74398xnF5plCdBzGhXMts8teet6Lptd
meHYYcruo0JxRcXOgeIUtLMnHJhbD6Vvgi7vFg43oZr2wQ2aGSNwVhhp1asnxupr
pmHuFX6OnCS3+gzxig5jzpZevLq+b/hCmu3vCIzpMbaUsC73DviRr6w6gC1P1dWg
mZ8N0q0LGRup8OelUAX/j2RitmGqi8OXlYEGY4cHYx18PWMVYJY=
=UKzV
-----END PGP SIGNATURE-----
Regards,
Nadav Ruskin
gregor herrmann
Jun 21, 2018, 6:20:03 PM6/21/18
to
Control: severity -1 wishlist
Control: retitle -1 debhelper: improve documentation for executable config files in debhelper(7)
On Mon, 18 Jun 2018 09:34:42 +0300, Nadav Ruskin wrote:
> I see! I understand now, thanks to your explanation. I can use your
> "stupid" script as a small hack to move development back to WSL. Thanks!
Great.
> I showed the documentation to a few of my colleagues and none of them could
> make use of it. It is not intuitive to any of us to expect a configuration
> file to be replaceable with an executable that echoes back configurations.
> Is this common practice in Linux? I highly recommend a simple explanation
> like the one you just said is added to the documentation.
I'm leaving this to the debhelper maintainers, while adjusting the
bug metadata.
Cheers,
gregor, just a happy debhelper user
Control: retitle -1 debhelper: improve documentation for executable config files in debhelper(7)
On Mon, 18 Jun 2018 09:34:42 +0300, Nadav Ruskin wrote:
> I see! I understand now, thanks to your explanation. I can use your
> "stupid" script as a small hack to move development back to WSL. Thanks!
> I showed the documentation to a few of my colleagues and none of them could
> make use of it. It is not intuitive to any of us to expect a configuration
> file to be replaceable with an executable that echoes back configurations.
> Is this common practice in Linux? I highly recommend a simple explanation
> like the one you just said is added to the documentation.
bug metadata.
Cheers,
gregor, just a happy debhelper user
0 new messages