Greg Hudson <ghudson@MIT.EDU> writes:
> I wasn't sure what to do about this.
>
> The various packaging maintainers have long appeared to take the
> attitude that it's appropriate to fix problems by adding kludges to the
> packaging materials rather than by submitting patches to the core
> Subversion code. Consequently, we get into the position where certain
> fringe functionality will work better (or perhaps just differently) if
> you install an RPM instead of building from source.
I don't have a good feel for how common this problem is, do you?
> r8085/r8104 is just another example of this attitude. I have a hard
> time voting for what I consider the wrong solution to a problem, even
> though it's consistent with the kind of things which have already gone
> into the packaging directory.
What's the specific problem in this case?
I have a vague understanding it's something like this: these rpm
changes make the book build process work (for the rpms), but that this
should really be a core change, so that the rpm process just uses the
standard build process for documentation.
But I don't understand technically what's broken with the book build
in core Subversion. I've built the book before, and it required
fetching a lot of tools, and even then still needed to be nursed along
sometimes, but that was due to very complex causes that I don't think
were due to anything in the build system itself.
It looks like the perl commands in r8085/r8104 are substituting some
paths to .xsl files. Are those paths are broken in normal Subversion?
I never had a problem with them before, but it's been a while since I
built the book...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 8 20:19:46 2004