Bill Allombert <[email protected]> writes: > 1) As written, the policy change induce maintainers to make changes to > their packages that will cause them to have a bug. This is not > acceptable.
> 2) As discussed previously, there are ways to tweak the process to avoid > this bug while keeping the advantage of this change, and so it should be > done. I'm happy to add a statement that packages should depend on dpkg (>= 1.15.4) | install-info if they contain info documents. I think that's a reasonable thing to do as part of the transition. Would that address these two concerns? > 3) Debian policy is not dpkg or any other package documentation. The > mere fact a package change its interface is not ground to update policy > without following the policy process (I am not claiming it ever > happened). I don't entirely agree. Policy needs to not be a roadblock for good things happening in Debian as long as there's general consensus. As long as we can get everything sorted out and consistent within a reasonable length of time, I think it's normal for Policy to not always be perfectly synchronized with other changes. There are, so far as I can see, two options going forward here: either we document how to make info documents work with the current system, since the previous documentation would result in buggy packages that aren't listed in /usr/share/info/dir, or we revert the change to install-info in the archive. Given that the install-info changes are both moving in the correct direction for the rest of the project (towards using triggers instead of maintainer scripts) and are part of resolving a very long-standing issue around divergence of the install-info command, I am opposed to reverting those changes. > 4) While I have no technical objection to the 'START-INFO-DIR-ENTRY' / > 'END-INFO-DIR-ENTRY' bits, currently at least one program generating > info files (debiandoc2info) does not follow them. Packages using it to > generate their info files would have a bug under this policy without an > easy way to fix it, so maybe it is a bit premature. How is there not an easy way to fix it? I can name a trivial way just off the top of my head: patch those lines into the generated files as part of the build system. Since they go at the top of the info file, the patch is reasonably stable. In fact, since they can always start at the third line of the file, you don't even need to use patch. A simple sed command would do it. Note also that this change is intentionally a should rather than a must, since info documents missing from the dir file is a bug but not an RC bug. This Policy change does not make any packages more buggy than they already are, since any info documents without this metadata are already missing from the dir file and hence already have a bug from the user's perspective. > 5) I am sorry to have to resort to a formal objection for issues which > are, in the big picture, small. However if less formal objections are > ignored, let it be that way. I read all of your objections. I just disagree with you, and so far as I could tell so did everyone else. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
