[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


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 :)


Michael Diers, elego Software Solutions GmbH, http://www.elego.de

Reply to: