Anders Kaseorg <ande...@mit.edu> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html