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
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.
What would that imply?
Would users have to modify the build script to add the Boost include
directory to the include path?
At the moment this is not necessary and I think requiring it is a bad
idea (for users that have to compile third-party code)
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
What is the advantage of having fewer symlinks?
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.
Is there documentation about the incompatibilities between 1.34 and 1.35?
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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
