search

repoforge / rpms

RepoForge.Org package specifications. This is where you can modify RepoForge.Org packages!
repoforge.org
300 stars 218 forks source link

subversion: update to 1.7.11, add 1.8.1. #292

Open kevbo-oh opened 11 years ago

kevbo-oh commented 11 years ago

I have done some work on Subversion. I started with the spec in the repo for version 1.7.6. It didn't work correctly (a reference to {rm} instead of %{rm}). I fixed that, and then updated it to version 1.7.11, adding some newer patches from Fedora, and removing some older things (references to local neon and Python that made the build fail). So, 1.7.11 should be working and available for rh6.

I then added subversion-1.8.spec, which will currently build 1.8.1. It is similar to the 1.7 spec, but with newer versions and patches. I had to add a patch to force an Apache module to build (in upstream, and Fedora, that particular module has moved to a -tools package that we don't create). I had to return to using a local build of sqlite-amalgation, because Subversion required a newer version. I had to add a line to the configure command to force the http modules to be installed where expected. This spec file can build 1.8.1 for rh6.

I haven't done any work on rh5.

kevbo-oh commented 11 years ago

I've since done some work at trying to get these to build for rh5.

I started with subversion-1.7.11.

rh5 has sqlite, but an older version, so the "local sqlite-amalgation" option needs to be enabled for it, just like rh6 needs for subversion-1.8.

rh5 doesn't have kde4, so the kdewallet stuff needs to be disabled for it.

But the dealbreaker happened next: Python. The Python bindings do not compile with Python < 2.5, and rh5 only has 2.4. The spec file doesn't easily have a way to disable making the Python bindings. Also, subversion on rh5 as originally shipped had the Python bindings, so not being able to make them is a problem.

This is where I stopped.

I don't know if the repoforge project has a way to note why a given package isn't being built for a given version any more, but that would be the reason for this one. It might be possible to keep going, to add hooks into the spec to not build the Python bindings, but then we would have packages that don't have the same files/features as the distro's packages do.

kevbo-oh commented 11 years ago

I've done a bit more in-depth looking at Subversion-1.8, and discovered an issue. Subversion can use an HTTP library to access Subversion servers through HTTP. Prior to 1.8, it defaulted to neon, but had the option to use serf. In 1.8, it drops neon support completely, and goes to serf.

So, I've done some work, and removed all references to neon. I tried to add serf support, but it isn't as "magic" as adding a local sqlite. Subversion's build system won't build serf: it has to be there already. The existing repoforge .spec file looks like it attempts to set up building neon: grabbing the source, decompressing it, moving it to a directory called just "neon". I did the same, but with serf, but it doesn't work: serf actually needs to be installed itself first, serf-1.2.1.

So, how do you guys handle something like this? Should I put together a serf-1.2.1 package, and make this depend on it? Or should I try to get subversion-1.8.spec to actually build/install/package what it needs of serf?

Actually, one other thing. EPEL already has a package for serf-1.2.1. I was under the impression that repoforge doesn't like to depend on anything not from the base distribution or itself. Is this still correct? If it is decided that subversion-1.8 could depend on a libserf RPM, then that RPM would also need to be part of repoforge, right?

So, this pull request is still find for subversion-1.7.11, but 1.8.1 will still require a bit of work. If you'd like, I could generate a new pull request with just the 1.7.11 stuff in it.

Please let me know which direction I should go with packaging serf. I can, and will, do it either way. I'd really like to see the Subversion 1.8 family as part of Repoforge.

kevbo-oh commented 11 years ago

I have successfully built a libserf and libserf-devel RPM for repoforge, and then rebuilt subversion-1.8 to use the built serf. So, if that's the way that you want to go, I can put together another pull request. Would you like 1 request (subversion-1.7, 1.8, and serf), two (1.7, and then 1.8 and serf) or three (one for each)?