Debian Bug report logs -
#980903
debhelper: doc-base doc-id deduplication does not work as documented with multiple "dh_installdocs -p<pkg>" calls; causes /usr/share/doc-base/<doc-id> to be installed multiple times
Reported by: Axel Beckert <abe@debian.org>
Date: Sun, 24 Jan 2021 04:51:02 UTC
Severity: important
Tags: patch
Found in version debhelper/13.3.1
Fixed in version debhelper/13.4
Done: Niels Thykier <niels@thykier.net>
Bug is archived. No further changes may be made.
Toggle useless messages
Report forwarded
to debian-bugs-dist@lists.debian.org, abe@debian.org, pkg-zsh-devel@lists.alioth.debian.org, Debhelper Maintainers <debhelper@packages.debian.org>:
Bug#980903; Package debhelper.
(Sun, 24 Jan 2021 04:51:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Axel Beckert <abe@debian.org>:
New Bug report received and forwarded. Copy sent to abe@debian.org, pkg-zsh-devel@lists.alioth.debian.org, Debhelper Maintainers <debhelper@packages.debian.org>.
(Sun, 24 Jan 2021 04:51:04 GMT) (full text, mbox, link).
Message #5 received at submit@bugs.debian.org (full text, mbox, reply):
Package: debhelper
Version: 13.3.1
Severity: serious
Justification: Causes file conflicts within binary packages of the same source package
Control: block 961757 by -1
While trying to solve https://bugs.debian.org/961757 ("Please install
the FAQ") in zsh, I ran into the following IMHO severe issue reported by
lintian at "warning level":
W: zsh source: binaries-have-file-conflict zsh-common zsh-doc usr/share/doc-base/zsh-faq
Scenario: I have two documents which I want to register with doc-base:
the Zsh Manual and the Zsh FAQ. Both are available in different file
formats. The FAQ is split over two binary packages (plain text in
zsh-common, HTML in zsh-doc) and I tried to use this technique described
in dh_installdocs man page:
debian/package.doc-base.*
If your package needs to register more than one document, you
need multiple doc-base files, and can name them like this. In
the event that multiple doc-base files of this style in a
single source package share the same doc-id, they will be
installed to usr/share/doc-base/package-* instead of
usr/share/doc-base/doc-id.
But this deduplication does not happen with zsh as the lintian warning
cited above shows.
I tried different file name combinations. Initially I had:
$ find debian -name '*doc-base*' | xargs fgrep Document:
debian/zsh-common.doc-base.faq:Document: zsh-faq
debian/zsh-doc.doc-base.faq:Document: zsh-faq
debian/zsh-doc.doc-base.manual:Document: zsh
Since there's only one document to register with in zsh-common, I tried
to use zsh-common.doc-base instead of zsh-common.doc-base.faq:
$ find debian -name '*doc-base*' | xargs fgrep Document:
debian/zsh-common.doc-base:Document: zsh-faq
debian/zsh-doc.doc-base.faq:Document: zsh-faq
debian/zsh-doc.doc-base.manual:Document: zsh
In both cases, there was indeed one file twice in the built binary
packages, as expected with different size:
$ debc | fgrep zsh-faq
-rw-r--r-- root/root 504 2021-01-24 00:45 ./usr/share/doc-base/zsh-faq
-rw-r--r-- root/root 519 2021-01-24 00:45 ./usr/share/doc-base/zsh-faq
After running the build with DH_VERBOSE=1, I found the reason: zsh's
debian/rules calls dh_installdocs multiple times with the -p<package>
option due to different options:
override_dh_installdocs-indep:
dh_installdocs -pzsh-doc --link-doc=zsh-common --doc-main-package=zsh-common
dh_installdocs -pzsh-common
But the documented deduplication only happens within a single
dh_installdocs call and is not spread over multiple calls.
So IMHO the value of %used_doc_ids needs to be cached somewhere under
debian/.debhelper/ or similar and if that cache file exists, it needs to
be read upon every dh_installdocs invocation.
Setting severity to RC as I think that debhelper should not be released
in bullseye with this issue being present, except if (worst case)
documented in dh_installdocs(1) as exception or (obviously) if fixed. (I
think being one of the top 5 committers of debhelper, I still can claim
that this is the maintainer's opinion, even though I haven't really
committed something for a few years and still have way less commits than
Niels has. I also intend to have a look into a solution, but if Niels is
quicker, he's of course free to fix it first. Hints are also
appreciated. ;-)
P.S.: The zsh package triggering this issue can be found in git in the
install-faq-961757 branch since I didn't want to commit this to the
normal packaging branch (called "debian" in this repo):
https://salsa.debian.org/debian/zsh/-/tree/install-faq-961757
P.P.S.: According to "git blame" this bug is in there since that feature
(see #525821) was added in debhelper 9.20130504. I quite surprised
that nobody else seems to have ran into it so far.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages debhelper depends on:
ii autotools-dev 20180224.1+nmu1
ii dh-autoreconf 19
ii dh-strip-nondeterminism 1.10.0-1
ii dpkg 1.20.7.1
ii dpkg-dev 1.20.7.1
ii dwz 0.13+20210118-1
ii file 1:5.39-3
ii libdebhelper-perl 13.3.1
ii libdpkg-perl 1.20.7.1
ii man-db 2.9.3-2
ii perl 5.32.0-6
ii po-debconf 1.0.21+nmu1
debhelper recommends no packages.
Versions of packages debhelper suggests:
ii dh-make 2.202003
-- no debconf information
Added indication that bug 980903 blocks 961757
Request was from Axel Beckert <abe@debian.org>
to submit@bugs.debian.org.
(Sun, 24 Jan 2021 04:51:04 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Debhelper Maintainers <debhelper@packages.debian.org>:
Bug#980903; Package debhelper.
(Sun, 24 Jan 2021 05:27:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Axel Beckert <abe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debhelper Maintainers <debhelper@packages.debian.org>.
(Sun, 24 Jan 2021 05:27:02 GMT) (full text, mbox, link).
Message #12 received at 980903@bugs.debian.org (full text, mbox, reply):
Hi,
braindump after further analysing this issue:
Axel Beckert wrote:
> override_dh_installdocs-indep:
> dh_installdocs -pzsh-doc --link-doc=zsh-common --doc-main-package=zsh-common
> dh_installdocs -pzsh-common
>
> But the documented deduplication only happens within a single
> dh_installdocs call and is not spread over multiple calls.
>
> So IMHO the value of %used_doc_ids needs to be cached somewhere under
> debian/.debhelper/ or similar and if that cache file exists, it needs to
> be read upon every dh_installdocs invocation.
This is uglier than I initially thought:
In the case above the doc-id is spread over two arch-indep packages,
so the all affected dh_installdocs calls are always either executed or
not, depending if only arch:all or only arch:any packages are built.
But if one dh_installdocs call is in override_dh_installdocs-arch and
one is in override_dh_installdocs-indep, the resulting package contents
differs depending if dpkg-buildpackage is building both, arch:all and
arch:any in one go, or separately.
This implies that you can scratch my initial idea of caching that
hash value.
Current idea is to _always_ use unique file names for
/usr/share/doc-base/, i.e. always use <package-name>.<doc-id> to be
unique. This also avoids the need for caching and makes things easier.
Then again, it changes the behaviour for other cases, too. Not sure
how appreciated this is at this stage of the freeze.
Any comments on this are appreciated.
Regards, Axel
--
,''`. | Axel Beckert <abe@debian.org>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Information forwarded
to debian-bugs-dist@lists.debian.org, Debhelper Maintainers <debhelper@packages.debian.org>:
Bug#980903; Package debhelper.
(Sun, 24 Jan 2021 06:24:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Axel Beckert <abe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debhelper Maintainers <debhelper@packages.debian.org>.
(Sun, 24 Jan 2021 06:24:02 GMT) (full text, mbox, link).
Message #17 received at 980903@bugs.debian.org (full text, mbox, reply):
Control: tag -1 + patch
Hi again,
Axel Beckert wrote:
> Current idea is to _always_ use unique file names for
> /usr/share/doc-base/, i.e. always use <package-name>.<doc-id> to be
> unique. This also avoids the need for caching and makes things easier.
I've now implemented this and the code is much simpler than beforehand:
https://salsa.debian.org/debian/debhelper/-/merge_requests/45
* The package builds fine and the build-time test suite passes
* The above mentioned zsh package now builds fine and as expected.
* doc-base behaves as expected on merging the two zsh-faq files after
installing those built zsh* packages.
* Salsa pipeline passed.
Will keep that debhelper test build installed locally and see if I run
into any issues while using it until a new debhelper release is
uploaded.
> Then again, it changes the behaviour for other cases, too. Not sure
> how appreciated this is at this stage of the freeze.
Still curious on this. :-)
Going to bed now. ;-)
Regards, Axel
--
,''`. | Axel Beckert <abe@debian.org>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Added tag(s) patch.
Request was from Axel Beckert <abe@debian.org>
to 980903-submit@bugs.debian.org.
(Sun, 24 Jan 2021 06:24:02 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Debhelper Maintainers <debhelper@packages.debian.org>:
Bug#980903; Package debhelper.
(Wed, 27 Jan 2021 17:45:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Niels Thykier <niels@thykier.net>:
Extra info received and forwarded to list. Copy sent to Debhelper Maintainers <debhelper@packages.debian.org>.
(Wed, 27 Jan 2021 17:45:03 GMT) (full text, mbox, link).
Message #24 received at 980903@bugs.debian.org (full text, mbox, reply):
Axel Beckert:
> Package: debhelper
> Version: 13.3.1
> Severity: serious
> Justification: Causes file conflicts within binary packages of the same source package
> Control: block 961757 by -1
>
>
> [...]
Hi Axel,
Thanks for filing the bug.
I have not examined this fully and I do not expect to be diving into the
details here any time soon.
Personally, it seems a bit like a "last minute bug" and I am do not feel
I have the necessary spoons to tackle it (or rather any fall out if it
goes less than perfectly smooth).
As it seems urgent to you and I suspect you have researched this (at
least much better than I will have energy to do for now), I am fine with
letting you manage it from here if you wish to do that.
Assuming you wish to have this fixed for bullseye, then I propose the
following:
1) Please base your work on debhelper's master branch. It is mostly
typo fixes and translation work. Please do commit directly to the
master branch.
2) I will expect you to handle the relevant release engineering
(i.e. uploads, unblock requests as necessary, etc.) along
with tackling regressions for this feature should any occurs.
(Feel free to upload debhelper using "Team Upload" rather than "NMU"
rules.)
3) Please do a call for updates to existing translations once you are
done or certain you will not need any more updates to the manpages.
- I am fine with doing a translation-only update after you are done,
so you do not need to follow up on that (unless you change strings
after the calls for translations).
I assume you are aware that it affects *every* doc-base package in the
archive and with the freeze approaching "work around sometimes required"
is better than "FTBFS bugs in packages that used to work".
Let me know if this arrangement sounds good to you or propose alternatives.
Thanks for considering,
~Niels
Information forwarded
to debian-bugs-dist@lists.debian.org, Debhelper Maintainers <debhelper@packages.debian.org>:
Bug#980903; Package debhelper.
(Wed, 27 Jan 2021 19:45:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Axel Beckert <abe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debhelper Maintainers <debhelper@packages.debian.org>.
(Wed, 27 Jan 2021 19:45:02 GMT) (full text, mbox, link).
Message #29 received at 980903@bugs.debian.org (full text, mbox, reply):
Hi Niels,
thanks for your reply!
TL;DR:
* Will probably go down the documentation update route for bullseye.
* I'm refusing to merge my own proposed patch without a review, at
least for bullseye.
* Reviews welcome nevertheless. :-)
Niels Thykier wrote:
> I have not examined this fully and I do not expect to be diving into the
> details here any time soon.
Yeah, I feared something like this after your comment in the according
zsh branch on Salsa which triggers this.
> Personally, it seems a bit like a "last minute bug"
Yes, it of course is. But not for the sake of making last minute
changes. I just discovered it in the wrong moment.
I would have filed it more or less the same in the midst of the
development cycle. (Well, maybe then even without that alternative "at
least document it". ;-)
> and I am do not feel I have the necessary spoons to tackle it (or
> rather any fall out if it goes less than perfectly smooth).
I feel competent enough to make further changes in case it causes
regressions. I'm though a bit unsure about its real impact, at least
as of now.
Running builds with and without it and then diffoscope it obviously
won't help as a change is to be expected.
> As it seems urgent to you
No, not "urgent". That's definitely the wrong term. It's more like
"important" (sic!).
But more in the way like there being an undiscovered bug which causes
broken packages to be build and nobody discovered it for a decade.
(Does the latter sound familiar to any one today? Ok, unfair, that
sudo issue is much more severe, but equally old and undiscovered until
recently as well. ;-)
Anyway, I also do recognize that this bug obviously hasn't been ever
triggered before (and then reported, at least). So while it is a bug
which causes debhelper to build uninstallable packages, it is
definitely rare. It needs at least these things to be present:
1. doc-base is used
2. multiple binary packages are build
3. dh_installdocs -p<pkg> is used at least twice (probably implies
2.).
4. one document ID is split over two built packages (and both are
present in the calls of 3.).
And now that I wrote that explicitly, I start to see that why this
combination is so rare that I only undiscovered a decade after the
code had been committed.
> and I suspect you have researched this (at least much better than I
> will have energy to do for now),
I've read all documentation I could find on this, but that's more or
less only dh_installdocs(1) (and the dh_installdocs source code in a
RTFS sense) on debhelper's side and
file://localhost/usr/share/doc/doc-base/doc-base.html/interface.html#s2.5.1
on doc-base's side.
In theory the actual filenames of the files in /usr/share/doc-base/
should not make a difference as long as they're unique.
I'm Cc'ing the doc-base maintainer to see if he can give some input on
this.
Robert: My proposed programmatical fix for this is in
https://salsa.debian.org/debian/debhelper/-/merge_requests/45
I'd be happy about a review, especially from someone understanding
doc-base and/or debhelper. That patch would change the filename
scheme, with which debhelper generates files in /usr/share/doc-base/
to always being "packagename.documentid" to avoid any file conflicts.
> I am fine with letting you manage it from here if you wish to do
> that.
Ok, fair enough.
So what I would like to have on this is at least a second pair of
eyes, because I'm very well aware of the potential impact of at least
my proposed solution.
Also to have it mentioned: For me it is way more important to me that
there's any fix for that (including documentation) than to have my
proposed fix in debhelper.
> Assuming you wish to have this fixed for bullseye,
As I wrote, I'm fine with proper documentation on this as alternative
to a code change as I do see that there is a potential for regressions
even though I don't see yet where actually a regression would be
possible. (But that's a common property of regressions, isn't it.)
So unless someone else does a (positive) review of my proposed patch,
I won't commit that one to the master branch.
But I will propose an alternative patch which purely updates
dh_installdocs' POD to explicitly mention this issue. IMHO this should
be no issue, even without a review and unless I get further feedback,
I'd go down that route and downgrade this bug-report to important
(which it technically would be without the "maintainer's opinion"
thing).
Niels: If you're more comfortable with that documentation approarch at
this stage at the freeze, I'm totally fine with going down that route
in any case for bullseye and leave the remainder open for bookworm.
Actually, the longer I think about it, the more I prefer that variant,
too. :-)
> then I propose the following:
>
> 1) Please base your work on debhelper's master branch.
I thought, I did. Will check. Ah, I see, you did some work there
today. Fair enough. :-)
> It is mostly typo fixes and translation work. Please do commit
> directly to the master branch.
>
> 2) I will expect you to handle the relevant release engineering
> (i.e. uploads, unblock requests as necessary, etc.) along
> with tackling regressions for this feature should any occurs.
Will do.
> (Feel free to upload debhelper using "Team Upload" rather than "NMU"
> rules.)
Yep, as mentioned, I still feel like belonging to the team, despite
more in a fifth wheel way with you being the other four wheels. ;-)
> 3) Please do a call for updates to existing translations once you are
> done
Done in git or done with a first upload?
> or certain you will not need any more updates to the manpages.
The pure documentation update will surely need updates.
> - I am fine with doing a translation-only update after you are done,
> so you do not need to follow up on that (unless you change strings
> after the calls for translations).
Ok, thanks. So I assume my question above is answered by "done with a
first upload".
> I assume you are aware that it affects *every* doc-base package in the
> archive
Yes, I fully am.
That's one of the reasons why I already included an alternative idea
in my initial bug report (the documentation update) and why I refuse
to just upload my proposed patch without a positive review by someone
else. :-)
> and with the freeze approaching "work around sometimes required"
> is better than "FTBFS bugs in packages that used to work".
Ack.
> Let me know if this arrangement sounds good to you or propose
> alternatives.
Totally fine with it.
Thanks for your time, especially since it seems scarce these days.
Regards, Axel
--
,''`. | Axel Beckert <abe@debian.org>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Information forwarded
to debian-bugs-dist@lists.debian.org, Debhelper Maintainers <debhelper@packages.debian.org>:
Bug#980903; Package debhelper.
(Sun, 31 Jan 2021 20:57:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Axel Beckert <abe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debhelper Maintainers <debhelper@packages.debian.org>.
(Sun, 31 Jan 2021 20:57:04 GMT) (full text, mbox, link).
Message #34 received at 980903@bugs.debian.org (full text, mbox, reply):
Control: severity -1 important
Hi Niels,
I've now added one paragraph to the POD of dh_installdocs:
Please be aware that this deduplication currently only works if
B<dh_installdocs> is called only once during the package build as
deduplication is done in memory only. Especially calling
B<dh_installdocs -p>I<package> in combination with using
F<debian/>I<package>F<.doc-base.*> files can lead to uninstallable
packages. See L<https://bugs.debian.org/980903> for details.
Cc'ing debian-l10n-english@l.d.o for input on this phrasing as per
https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html#write-correct-english
I also regenerated to .po files and committed them, too, in a separate
commit and pushed both commits to master.
Axel Beckert wrote:
> > Assuming you wish to have this fixed for bullseye,
>
> As I wrote, I'm fine with proper documentation on this as alternative
> to a code change as I do see that there is a potential for regressions
> even though I don't see yet where actually a regression would be
> possible. (But that's a common property of regressions, isn't it.)
>
> So unless someone else does a (positive) review of my proposed patch,
> I won't commit that one to the master branch.
Didn't get any feedback so far, so I went down the "document the
issue" route. Downgraded the bug report accordingly with this mail,
too.
> > 1) Please base your work on debhelper's master branch.
Done for the documentation part. Will rebase the other branch with the
actual fix later, too.
> > 2) I will expect you to handle the relevant release engineering
> > (i.e. uploads, unblock requests as necessary, etc.) along
> > with tackling regressions for this feature should any occurs.
>
> Will do.
>
> > (Feel free to upload debhelper using "Team Upload" rather than "NMU"
> > rules.)
>
> Yep, as mentioned, I still feel like belonging to the team, despite
> more in a fifth wheel way with you being the other four wheels. ;-)
>
> > 3) Please do a call for updates to existing translations once you are
> > done
>
> Done in git or done with a first upload?
[…]
> > - I am fine with doing a translation-only update after you are done,
> > so you do not need to follow up on that (unless you change strings
> > after the calls for translations).
>
> Ok, thanks. So I assume my question above is answered by "done with a
> first upload".
I still think I should first ask debian-l10n-english. Done herewith,
see above.
Regards, Axel
--
,''`. | Axel Beckert <abe@debian.org>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Severity set to 'important' from 'serious'
Request was from Axel Beckert <abe@debian.org>
to 980903-submit@bugs.debian.org.
(Sun, 31 Jan 2021 20:57:04 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Debhelper Maintainers <debhelper@packages.debian.org>:
Bug#980903; Package debhelper.
(Sun, 31 Jan 2021 21:33:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Justin B Rye <justin.byam.rye@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debhelper Maintainers <debhelper@packages.debian.org>.
(Sun, 31 Jan 2021 21:33:04 GMT) (full text, mbox, link).
Message #41 received at 980903@bugs.debian.org (full text, mbox, reply):
Axel Beckert wrote:
> I've now added one paragraph to the POD of dh_installdocs:
>
> Please be aware that this deduplication currently only works if
> B<dh_installdocs> is called only once during the package build as
> deduplication is done in memory only. Especially calling
> B<dh_installdocs -p>I<package> in combination with using
> F<debian/>I<package>F<.doc-base.*> files can lead to uninstallable
> packages. See L<https://bugs.debian.org/980903> for details.
>
> Cc'ing debian-l10n-english@l.d.o for input on this phrasing as per
> https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html#write-correct-english
It's grammatical and I believe it says what you need it to say, but
I'd be happier with it if it had fewer uses of "only" per sentence...
Please be aware that this deduplication is currently done in memory
only, so it requires B<dh_installdocs> to be called no more than
once during the package build. Calling B<dh_installdocs -p>I<package>
in combination with using F<debian/>I<package>F<.doc-base.*> files
can lead to uninstallable packages. See
L<https://bugs.debian.org/980903> for details.
(Is it still accurate with the "currently" relocated like this, or
does it need to be before "requires"?)
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Information forwarded
to debian-bugs-dist@lists.debian.org, Debhelper Maintainers <debhelper@packages.debian.org>:
Bug#980903; Package debhelper.
(Sun, 31 Jan 2021 22:03:07 GMT) (full text, mbox, link).
Acknowledgement sent
to Axel Beckert <abe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debhelper Maintainers <debhelper@packages.debian.org>.
(Sun, 31 Jan 2021 22:03:07 GMT) (full text, mbox, link).
Message #46 received at 980903@bugs.debian.org (full text, mbox, reply):
Hi Justin,
thanks for your prompt reply,
Justin B Rye wrote:
> > I've now added one paragraph to the POD of dh_installdocs:
> >
> > Please be aware that this deduplication currently only works if
> > B<dh_installdocs> is called only once during the package build as
> > deduplication is done in memory only. Especially calling
> > B<dh_installdocs -p>I<package> in combination with using
> > F<debian/>I<package>F<.doc-base.*> files can lead to uninstallable
> > packages. See L<https://bugs.debian.org/980903> for details.
[…]
> It's grammatical and I believe it says what you need it to say,
Thanks!
> but I'd be happier with it if it had fewer uses of "only" per
> sentence...
Hehe, good point.
> Please be aware that this deduplication is currently done in memory
> only, so it requires B<dh_installdocs> to be called no more than
> once during the package build. Calling B<dh_installdocs -p>I<package>
> in combination with using F<debian/>I<package>F<.doc-base.*> files
> can lead to uninstallable packages. See
> L<https://bugs.debian.org/980903> for details.
>
> (Is it still accurate with the "currently" relocated like this, or
> does it need to be before "requires"?)
My gut feeling says it's needed in both places. Would that be too
much? Would "so for now it requires" be an acceptable alternative to
using "currently" twice?
Context: I've prepared a patch which will hopefully fix this in the
future, but it's likely too invasive for bullseye. So this text will
be in there only until #980903 will be fixed properly.
Regards, Axel
--
,''`. | Axel Beckert <abe@debian.org>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Information forwarded
to debian-bugs-dist@lists.debian.org, Debhelper Maintainers <debhelper@packages.debian.org>:
Bug#980903; Package debhelper.
(Sun, 31 Jan 2021 22:21:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Justin B Rye <justin.byam.rye@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debhelper Maintainers <debhelper@packages.debian.org>.
(Sun, 31 Jan 2021 22:21:02 GMT) (full text, mbox, link).
Message #51 received at 980903@bugs.debian.org (full text, mbox, reply):
Axel Beckert wrote:
> Justin B Rye wrote:
>> Please be aware that this deduplication is currently done in memory
>> only, so it requires B<dh_installdocs> to be called no more than
>> once during the package build. Calling B<dh_installdocs -p>I<package>
>> in combination with using F<debian/>I<package>F<.doc-base.*> files
>> can lead to uninstallable packages. See
>> L<https://bugs.debian.org/980903> for details.
>>
>> (Is it still accurate with the "currently" relocated like this, or
>> does it need to be before "requires"?)
>
> My gut feeling says it's needed in both places. Would that be too
> much? Would "so for now it requires" be an acceptable alternative to
> using "currently" twice?
That alternative works nicely, yes.
> Context: I've prepared a patch which will hopefully fix this in the
> future, but it's likely too invasive for bullseye. So this text will
> be in there only until #980903 will be fixed properly.
Good luck with that!
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Information forwarded
to debian-bugs-dist@lists.debian.org, Debhelper Maintainers <debhelper@packages.debian.org>:
Bug#980903; Package debhelper.
(Fri, 23 Apr 2021 15:21:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Vedarius Russell <Varussell23@outlook.com>:
Extra info received and forwarded to list. Copy sent to Debhelper Maintainers <debhelper@packages.debian.org>.
(Fri, 23 Apr 2021 15:21:04 GMT) (full text, mbox, link).
Message #56 received at 980903@bugs.debian.org (full text, mbox, reply):
Bugs
Vedarius A. Russell
Information forwarded
to debian-bugs-dist@lists.debian.org, Debhelper Maintainers <debhelper@packages.debian.org>:
Bug#980903; Package debhelper.
(Fri, 23 Apr 2021 15:21:05 GMT) (full text, mbox, link).
Acknowledgement sent
to Vedarius Russell <Varussell23@outlook.com>:
Extra info received and forwarded to list. Copy sent to Debhelper Maintainers <debhelper@packages.debian.org>.
(Fri, 23 Apr 2021 15:21:05 GMT) (full text, mbox, link).
Message #61 received at 980903@bugs.debian.org (full text, mbox, reply):
On Sun, 24 Jan 2021 05:47:18 +0100 Axel Beckert wrote:
> Package: debhelper
> Version: 13.3.1
> Severity: serious
> Justification: Causes file conflicts within binary packages of the same source package
> Control: block 961757 by -1
>
> While trying to solve https://bugs.debian.org/961757 ("Please install
> the FAQ") in zsh, I ran into the following IMHO severe issue reported by
> lintian at "warning level":
>
> W: zsh source: binaries-have-file-conflict zsh-common zsh-doc usr/share/doc-base/zsh-faq
>
> Scenario: I have two documents which I want to register with doc-base:
> the Zsh Manual and the Zsh FAQ. Both are available in different file
> formats. The FAQ is split over two binary packages (plain text in
> zsh-common, HTML in zsh-doc) and I tried to use this technique described
> in dh_installdocs man page:
>
> debian/package.doc-base.*
> If your package needs to register more than one document, you
> need multiple doc-base files, and can name them like this. In
> the event that multiple doc-base files of this style in a
> single source package share the same doc-id, they will be
> installed to usr/share/doc-base/package-* instead of
> usr/share/doc-base/doc-id.
>
> But this deduplication does not happen with zsh as the lintian warning
> cited above shows.
>
> I tried different file name combinations. Initially I had:
>
> $ find debian -name '*doc-base*' | xargs fgrep Document:
> debian/zsh-common.doc-base.faq:Document: zsh-faq
> debian/zsh-doc.doc-base.faq:Document: zsh-faq
> debian/zsh-doc.doc-base.manual:Document: zsh
>
> Since there's only one document to register with in zsh-common, I tried
> to use zsh-common.doc-base instead of zsh-common.doc-base.faq:
>
> $ find debian -name '*doc-base*' | xargs fgrep Document:
> debian/zsh-common.doc-base:Document: zsh-faq
> debian/zsh-doc.doc-base.faq:Document: zsh-faq
> debian/zsh-doc.doc-base.manual:Document: zsh
>
> In both cases, there was indeed one file twice in the built binary
> packages, as expected with different size:
>
> $ debc | fgrep zsh-faq
> -rw-r--r-- root/root 504 2021-01-24 00:45 ./usr/share/doc-base/zsh-faq
> -rw-r--r-- root/root 519 2021-01-24 00:45 ./usr/share/doc-base/zsh-faq
>
> After running the build with DH_VERBOSE=1, I found the reason: zsh's
> debian/rules calls dh_installdocs multiple times with the -p
> option due to different options:
>
> override_dh_installdocs-indep:
> dh_installdocs -pzsh-doc --link-doc=zsh-common --doc-main-package=zsh-common
> dh_installdocs -pzsh-common
>
> But the documented deduplication only happens within a single
Vedarius A. Russell
Reply sent
to Niels Thykier <niels@thykier.net>:
You have taken responsibility.
(Tue, 17 Aug 2021 16:51:07 GMT) (full text, mbox, link).
Notification sent
to Axel Beckert <abe@debian.org>:
Bug acknowledged by developer.
(Tue, 17 Aug 2021 16:51:07 GMT) (full text, mbox, link).
Message #66 received at 980903-close@bugs.debian.org (full text, mbox, reply):
Source: debhelper
Source-Version: 13.4
Done: Niels Thykier <niels@thykier.net>
We believe that the bug you reported is fixed in the latest version of
debhelper, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 980903@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Niels Thykier <niels@thykier.net> (supplier of updated debhelper package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Tue, 17 Aug 2021 16:32:34 +0000
Source: debhelper
Architecture: source
Version: 13.4
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers <debhelper@packages.debian.org>
Changed-By: Niels Thykier <niels@thykier.net>
Closes: 908845 979401 980903 981106 983566 986329 987989 988973 989155
Changes:
debhelper (13.4) unstable; urgency=medium
.
[ Dimitri John Ledkov ]
* dh_dwz: run in parallel across packages. (Closes: !47)
.
[ Andrej Shadura ]
* Dh_Buildsystems.pm: Add bmake and mkcmake as third-party
build systems. (Closes: !46)
.
[ Guillem Jover ]
* Dh_Buildsystems.pm: Add golang as a third-party build
system. (Closes: #981106)
.
[ Niels Thykier ]
* autoscripts/*: Add support for DPKG_ROOT in systemd, tmpusers,
sysusers and init related snippets. Based on an initial patch
from Helmut Grohne. (Closes: #983566)
* autoscripts/*: Reorder conditions in some scripts to avoid
doing a redundant stat call when a script parameter can decide
to skip it.
* dh_gconf: Remove the command as it does nothing.
(Closes: #908845)
* doc/TODO: Remove reference to dh_gconf.
* root_sequence.pm: Remove dh_gconf from root sequence and declare
it as obsolete (causing errors from compat 14 if still referenced
in hook targets).
* man/po4a/po4a.cfg: Remove dh_gconf from translations.
* AddonAPI.pm: The declare_command_obsolete command now accepts an
"$error_compat" parameter to enable addons to choose which compat
level that will trigger an error (though it must be minimum 13).
* doc/PROGRAMMING: Update docs to reflect API change.
* debhelper.pod: Document that referencing dh_gconf in hook targets
will cause an error in compat 14.
* dh_fixperms: Correct permissions of files beneath usr/libexec to
be executable. (Closes: #979401)
* dh_installtmpfiles: Only register tmpfiles ending with ".conf" as
tmpfiles in /usr/lib/tmpfiles.d and /etc/tmpfiles.d. This ensures
that dh_installtmpfiles gracefully copes with e.g. README files
provided by systemd upstream. (Closes: #986329)
* dh_installsystemd: Ditto (but only relevant in compat 12 or
earlier)
* cmake.pm: Pass -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF to cmake in
addition to -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON as the
former is intended to replace the latter. Thanks to Raul Tambre
for reporting the issue. (Closes: #988973)
* Dh_Lib.pm: Bump version requirement to v5.28 to reflect the actual
requirements (the code was using v5.28 features). Thanks to
Sérgio Basto for reporting the issue.
* dh_missing: Ditto.
* autoscripts/postinst-init,autoscripts/postinst-systemd-start: Use
"restart" instead of "start" when starting the services. This
ensures a smooth transition from --restart-after-upgrade to
--no-restart-after-upgrade in dh_installinit and dh_installsystemd.
Thanks to Ryan Tandy for reporting the issue.
(Closes: #989155)
* dh_installsystemd: Remove usage of autoscripts/postinst-systemd-restart
* dh_installinit: Remove usage of autoscripts/postinst-init-restart
* autoscripts/autoscripts/postinst-systemd-restart: Removed.
* autoscripts/postinst-init-restart: Removed
* dh_installsystemd: Prefer /usr/lib/systemd/ to /lib/systemd.
(Closes: #987989)
* dh_systemd_enable: Ditto.
* dh_systemd_start: Ditto.
* dh_installinit: Ditto.
* dh_installsystemd: Merge /lib/systemd into /usr/lib/systemd if both
are present in the package staging directory (prefering the latter
in case of conflicts). (Closes: #987989)
* dh_systemd_enable: Ditto.
.
[ Dominic Hargreaves ]
* perl_build.pm,perl_makemaker.pm: Make debhelper use the same perl
as it runs under (via Perl's $^X variable) when invoking the
upstream build system. (Closes: !40, #966396)
.
[ Axel Beckert ]
* Always generate unique doc-base file names based on package name and
document ID. (Closes: #980903)
Checksums-Sha1:
3bc75e1b09e1bbc377dc1642681e779c759148d0 1781 debhelper_13.4.dsc
6d77b2a118dbb0817c6a7dffb981b8b820367f2a 556308 debhelper_13.4.tar.xz
7e6b3982dbcbc7fe837aa19c1ceaff73c6667d70 4981 debhelper_13.4_source.buildinfo
Checksums-Sha256:
fccb5935bc6e79cef8fecaf7f90de227f796334c2a05d2dc462bc715366ecc88 1781 debhelper_13.4.dsc
668d8d16e788f3900d8356dbb3c1eab34ccf45cafb5ecb8a6ff5a71b804661ce 556308 debhelper_13.4.tar.xz
9a7b2ebcc76f4d5399505c54b32582a22ff12d36eedab633ce00d14a34646d40 4981 debhelper_13.4_source.buildinfo
Files:
221f553d4f4b9c374ae9e98efeb3b008 1781 devel optional debhelper_13.4.dsc
9f9414556d1ff4b5b08725f2f6df8338 556308 devel optional debhelper_13.4.tar.xz
eba2add6f68dc338700f512f2b8b8d53 4981 devel optional debhelper_13.4_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQJGBAEBCgAwFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAmEb5bUSHG5pZWxzQHRo
eWtpZXIubmV0AAoJEKZbeNvmfHqsfWMP/je+aZ9b56K3yT7zlu5RnEeAAVClOp/8
xtu3QqYx3Ap00yjbX97TxFNCLdZ2z7J6hoKoQg3iTm6bOvKN7kM4IM8R4ywdYmY6
3ebfKkZ5T+9EV2Dmxkqu/l2bOTGy7hhxUYrkmkAFji2I0vSncNTkyb6JOeR2Wa9r
ZD/5HfrC3aj0jDZfQmHxUdDiQKzmpa7GOxjH2t+uAJEJd61wbeErWOe1ALvpTjgl
FdzsIuZIQrUR3EM+uwd3397ZByJtxLI5O10E/GH48jJebzbBvNp+dRCCifqQyY7d
fpYaRroqhKSZ7vIgvDSLuqtC38z9cKOkldUjN6W2M7ddjcsueBRGuG7UcIfbDhz8
cGLJOWmOwdV9v1ZNW7/nDtRCOLcxaRs7VHEL1SNc4AJHjMJnU/l0AVeEbpnk82Bu
W3e4UGd6qaUQvJ8ibrnsJE6oRteXsXjs9WItKLC++WeP4bFOL4MesF0e4Cpx3xZg
+DGfkDib8oqMCbkPV6XJd8UI/sX8QWEsYinJH4+82zTLY0HBTgtuAEi0gKD0bGty
HkpVoGpIN/iOkqNEuypX09Ek3KkprIJFjs19AFea23VPCljNBU41pDNxLSp9nFyA
Cux3sVO/p3ysmcCm/mVqB1T7C7aGCJJ+BjywVcL2vvmDx5j80UyVwu0D0QVtXxi1
biXVFfWgqzBg
=qP2Q
-----END PGP SIGNATURE-----
Bug archived.
Request was from Debbugs Internal Request <owner@bugs.debian.org>
to internal_control@bugs.debian.org.
(Wed, 15 Sep 2021 07:24:56 GMT) (full text, mbox, link).
Send a report that this bug log contains spam.
Debian bug tracking system administrator <owner@bugs.debian.org>.
Last modified:
Thu Mar 9 10:55:51 2023;
Machine Name:
buxtehude
Debian Bug tracking system
Debbugs is free software and licensed under the terms of the GNU
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.