Anders Kaseorg <andersk@xxxxxxx> writes: > Yes; when I noticed this failure, I asked Jonathan to add source-highlight > as a build dependency in Debian (https://bugs.debian.org/745591). But > then Ubuntu forked the packaging to revert this change > (https://bugs.launchpad.net/bugs/1316810), because source-highlight in the > community-supported universe repository is not allowed to be a build > dependency ... The reasoning and solution Ubuntu has sounds sensible *but* it also soudns like it is incomplete. If Ubuntu does not want to use highlight, it can apply a change like the patch in question as part of their fork to make the end result consistent and they are failing to do so. If the tooling do not use highlight, the source should not require highlight, either. It is ultimately their bug. It however *is* our business, as their upstream, to make it easier for distros that want to use and distros that do not want to depend on highlight, and aiming for a solution that relieves Ubuntu or any other distros from needing to carry one more patch is a good thing. How bad does the documentation look with the patch applied (I know how bad it looks without source-highlight installed)? If it is not too bad, then it sounds like a sensible solution to drop the highlight markup unconditionally like the patch that started this thread does, taking the "common denominator" approach. You seem to agree, and I do not object, either. > But I don’t that would be worth it just to make one page of the API > documentation a little more colorful (and it sounds like you agree). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html