[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r8190 - branches/1.0-stabilization

From: <kfogel_at_collab.net>
Date: 2004-01-08 19:25:19 CET

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.