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 take 1.35 as > they like
I think we might as well support multiple boost versions. As you
point out, there is a big advantage in not forcing a transition each
time Boost releases.
The remaining question is whether we support co-installation of
multiple -dev packages. The fact that Boost upstream *does* support
this -- by embedding the boost version into both the link library and
the include directory names -- makes me lean towards this option. I'd
appreciate hearing any concerns regarding this. Olaf van der Spek has
already voiced one:
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 problem. I'm not sure what
can be done about it besides having the two boost-using libs upgrade
together.
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
provide such defaults? I fear the first option will bring us back to
the same misery we currently suffer with transitions. So I'm fine
with not providing defaults, which is in line with upstream practices
anyway.
> I could make sush package but I need the point about the SVN repository.
> Steve, I saw the transition of boost-jam to merge-upstream-mode, which
> are your plans for boost?
I have already changed boost to merge-upstream-mode; hope you're OK
with that.
I've finished the initial packaging of 1.35.0 and checked it in to
SVN. It currently uses the same scheme we've always used, with
unversioned -dev packages. I did, however, patch upstream to remove
the toolset from the library names so there are fewer symlinks. It's
not uploaded to experimental; I'm reconsidering the wisdom of doing
so, since we should be able to get 1.35 packages (co-installable with
1.34.1) uploaded directly to unstable.
I also removed the Boost library version from the link library names.
However, reflecting upon what you say, I suppose we really prefer to
have version X-dev and version (X+1)-dev co-installable. If so, we
would revert that change and adjust the rules accordingly.
By the way, before starting to fiddle with 1.35, I branched the trunk
to pkg-boost/boost/branches/1.34.1. My thought is that any further
development for 1.34.1 would live there. When the next boost version
is released, we would again branch the trunk to branches/1.35.0 and
work there for 1.35.0.
Chimo,
-Steve
signature.asc
Description: Digital signature
