On Sat, Apr 19, 2008 at 10:43 PM, Steve M. Robbins [EMAIL PROTECTED] wrote:
Can a process load 1.34 and 1.35 at the same time? Otherwise
maybe you've got a problem if one lib uses 1.34 and another lib
uses 1.35 and parts are exposed.
I think you're right that there could be a
Steve M. Robbins wrote:
On Sat, Apr 19, 2008 at 10:53:35PM +0200, Olaf van der Spek wrote:
Steve M. Robbins wrote:
If we do decide to have co-installable -dev packages, the next
question is how do we handle the current non-versioned includes and
link libraries? Do we follow what gcc and
On Sat, Apr 19, 2008 at 10:53:35PM +0200, Olaf van der Spek wrote:
Steve M. Robbins wrote:
If we do decide to have co-installable -dev packages, the next
question is how do we handle the current non-versioned includes and
link libraries? Do we follow what gcc and python do, providing a
On Fri, Apr 18, 2008 at 12:20:39PM +0200, Domenico Andreoli wrote:
I think new and separate boost-1.35 package is the best option we have:
1. It may be uploaded now and released with lenny without touching
any reverse dependency
2. Never more huge transitions, reverse dependencies
Steve M. Robbins wrote:
If we do decide to have co-installable -dev packages, the next
question is how do we handle the current non-versioned includes and
link libraries? Do we follow what gcc and python do, providing a
defaults that change from time to time? Or should we not attempt to
Hi,
On Fri, Apr 11, 2008 at 04:13:05PM -0500, Steve M. Robbins wrote:
On Fri, Apr 11, 2008 at 03:13:15PM -0400, Joshua Judson Rosen wrote:
If you guys need some help, I can try updating the packaging for 1.35.
Packaging is not the issue, however. I think I can do that over the
weekend.
6 matches
Mail list logo
