[pkg-boost-devel] Upload of Boost 1.38

[Steve M. Robbins]

Hello release team,

On Fri, Mar 20, 2009 at 09:13:34PM +0100, Adeodato Sim?? wrote:

> Once boost1.38 is built in all architectures and migrated to
> testing, we can proceed with the boost-defaults plans, see below
> about this.

OK, boost1.38 is built and in testing, so I'm preparing boost-defaults
now.  I've got a preliminary package of it at
http://svn.debian.org/wsvn/pkg-boost/boost-defaults/trunk/#_boost-defaults_trunk_

Basically all it has is a control file with unversioned -dev packages
that depend on the corresponding 1.38-dev package.  I'd appreciate it
if you would give it a glance and see whether I've missed something.

I realize that most other -defaults generate control from a template
and substitute in the version string; I plan to do the same when 1.39
comes out.  Are there other improvements I could make?


> I suggest that we get started by introducing boost1.38 in unstable, and
> once it has migrated to testing, start the migration work. This means:
> 
>   * an initial upload of boost-defaults providing versionless -dev
>     package names pointing at the 1.38 packages

After creating boost-defaults, I realized that the existing
libboost1.38-dev package has an unversioned conflict with libboost-dev
(currently from boost 1.34.1) so I could not install the new
libboost-dev from boost-defaults.  I uploaded a new version of
boost1.38 where the conflict is now versioned and local testing
suggests this solves my problem.

Unfortunately, however, the new upload fails to compile on a few
architectures (ICE on s390, MPI problem on MIPS).  Thus, while boost
1.38.0-3 is in testing, the new -4 upload will not migrate until such
problems are fixed.  Shall I go ahead and upload boost-defaults anyway
or would you prefer to wait until the latest boost 1.38 hits testing?

Thanks,
-Steve

P.S. After boost-defaults is uploaded, the archive will have two
source packages (boost, boost-defaults) that both produce the
binary package libboost-dev.  Won't that cause a problem?  Does
something need to be adjusted to allow this?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-boost-devel/attachments/20090424/9370f885/attachment.pgp>