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 <a...@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
