Re: RFS: subversion (updated package) [lenny-backports, 1.6.12dfsg-1~bpo50+2]
On 2010-07-03 05:54, Matt Taggart wrote:
> Hi Michael,
>
> Just a couple comments based on the changelog, I haven't looked at the
> packages.
Matt,
thanks a bundle for having a look.
>>> subversion (1.6.12dfsg-1~bpo50+2) lenny-backports; urgency=medium
>>>
>>> * Rebuild for lenny-backports.
>>> * Disable ra_serf, need a newer version than the one in lenny.
>
> How about backporting a newer serf instead so you don't have to lose the
> functionality? As long as the build dependencies and dependencies are
> versioned properly (and you know they already are) then everything will
> just work at build time and run time. The BPO buildd's are also smart
> enough to deal with it.
>
> It looks like it backports cleanly with no changes.
>
> (BTW if you run into a reason why the package doesn't build or run because
> it needs a versioned build-dep/dep to the backport and also file a bug on
> the package to have it added)
Yes, that would be pretty easy to do. Previous 1.6.x lenny-backports did
not require the updated serf, though. Not sure if it'a a good thing to
introduce a new run-time dependency at this point in time.
>>> * Build-depend on libdb4.6-dev, suggest db4.6-util.
>>> * Build-depend on openjdk-6-jdk instead of gcj-jdk.
>>> * Depend on openjdk-6-jre-headless instead of gij.
>
> I think these probably make more sense than trying to backport all that
> stuff (assuming everything still works OK with the older versions).
Well, that's backports.org policy. Admittedly not the OpenJDK part, but
the libdb4.6 bit. One blends in with the "stable" run-time environment.
>
>>> * control: Fix version control URLs.
>
> I wouldn't bother fixing these for the backport.
OK, but then again the backport changes are in a different branch than
the "testing" source. Moreover, the bpo50+1 version control URLs were
wrong. And I had to touch debian/control anyway. So there :)
Cheers,
--
Michael Diers, elego Software Solutions GmbH, http://www.elego.de
Reply to: