Your message dated Fri, 07 Oct 2016 09:29:49 +0200
with message-id <[email protected]>
and subject line Re: dh-exec: Specify optional files that should be installed
when available
has caused the Debian Bug report #811064,
regarding dh-exec: Specify optional files that should be installed when
available
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.)
--
811064: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811064
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dh-exec
Version: 0.23
Severity: wishlist
Sometimes I would like to install files when they are available, and not
have to hardcode the precise list of conditions under which they are
available or not.
For example, I hade to make the pandoc build-dependency conditional so
that it does not apply on armel (it's currently not available there).
When pandoc is not available, manual pages were not built and thus
the entries in *.install generated failures with dh_install.
I fixed those with dh-exec using this syntax:
[!armel] usr/share/man/man3/libmaxminddb.3
But if pandoc disappears on another architecture, I will have to update
the condition there too. I would much prefer if I could just say "install
this file if it's there, otherwise just ignore it". In other places (like
udeb module list), we can use a question mark as prefix or suffix to make
the line optional.
So it would be nice if we could write this:
#!/usr/bin/dh-exec
? usr/share/man/man3/libmaxminddb.3
? usr/share/man/man1/*
And if the file cannot be found (or if the wildcard matches nothing),
then the line gets dropped before being fed to dh_install.
Cheers,
-- System Information:
Debian Release: stretch/sid
APT prefers squeeze-lts
APT policy: (500, 'squeeze-lts'), (500, 'oldoldstable'), (500, 'unstable'),
(500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages dh-exec depends on:
ii debhelper 9.20151225
ii libc6 2.21-6
ii libdpkg-perl 1.18.4
ii libpipeline1 1.4.1-2
iu perl 5.22.1-4
dh-exec recommends no packages.
dh-exec suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Control: tag -1 wontfix
Hi,
I have been pondering about this recently - and it has been on my mind,
on and off, for the most part of the year -, and I'm a bit torn. On one
hand, I understand the desire to make it simpler to exclude files from
installing, or to have only one place to control architecture
restrictions. On the other hand, I also understand the desire to have
clarity.
To shed light on my decision, I'll try to explain the process that led
up to it. In the beginning, I was sympathetic, because making
developers' lives easier is one of the reasons dh-exec exists. It's also
a big hack, anyway. Yet, in the past, there have been a lot of cases
where a little bit of uncertainty ended up causing a lot of issues.
During the past months, I have had to deal with way too many issues that
all started from one single problem: the lack of explicitness, and
reliance on the optional. Packages missing half their functionality,
because "that tool will be there, anyway!", or "some other package we
depend on/recommend will pull in other stuff!", and a number of other,
similar things. These are terribly annoying to fix. It is even harder to
figure out - for someone unfamiliar with the package - why something is
not explicitly specified.
There are parts of dh-exec which are less clear than they could be, but
in the end, my goal is not only to make it easier for maintainers to do
their jobs, but to make it similarly easy for other maintainers (or any
other interested party) to understand and work with the results. For
this reason, explicitness is king, and any magic that would need its
whys further explained, is something I'd like to avoid, if at all
possible.
While I recognise that the "?"-style optional syntax would be a big help
in some cases, I do not think that this ease is worth the cost. Someone
not familiar with the package or its history, would have to figure out
why the "?" is there, and whether it applies to their situation. When
something is missing from the package, it would not be immediately clear
why. We already have lots of these small uncertainties in the archive,
lets not add even more.
For these reasons, I will not be implementing this feature, I'm afraid.
--
|8]
--- End Message ---
