[pkg-boost-devel] Upload of Boost 1.38

[Adeodato Simó]

+ Steve M. Robbins (Fri, 24 Apr 2009 00:29:04 -0500):

> Hello release team,

Hello,

> 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_

For the love of Pete I couldn't get a "show me the file contents" option
with that link. I resorted to ViewSVN.

> 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.

Let's make the unversioned development packages arch:any, and
build-depend on libboost1.38-dev. That way, even if the intent is to
only bump the major version when eg. boost1.39 is built everywhere, it
should be less problematic (ie. no uninstallable -dev) if it gets done
before, either on purpose or accidentally.

> 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.

Okay, please do that. That way, the hypothetical accidental upload
mentioned above would get to build-depend on libboost1.39-dev and not on
libboost1.38-dev because the uploader forgot to update it.

> Are there other improvements I could make?

Not that I can think of, apart from the arch:any bit, and the
build-dependency.

> > 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?

Iff packages built against libboost1.38-dev 1.38.0-4 generate
dependencies that are satisfiable in testing (ie., that don't require
-4), you can upload iff you make the build-dependency of boost-defaults
on libboost1.38-dev versioned >= 1.38.0-4. Otherwise we'd have
uninstallable -dev packages, which we do not want. Please note there are
*two* "iff". :-)

I'm unsure what is causing the failure on mips. Do you have any ideas?
But the mipsen buildds are having toolchain troubles, so it may be worth
delaying investigations until those are fixed, which should happen
during this week.

> 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?

Frank already replied and his answer is canonical since he's ftpteam.
Quoting from http://lists.debian.org/debian-release/2009/03/msg00345.html:

  | > This seems like a reasonable proposal.  Do you forsee that we can
  | > upload boost-defaults to sid with boost 1.34.1 (also providing
  | > versionless -dev packages) still in the archive?  When does 1.34.1 get
  | > removed?
  | 
  | Yes, it’s technically feasible, and boost 1.34.1 would get removed once
  | it would have no reverse dependencies left. (If a boost 1.34 upload was
  | needed, though, it would have not to include the -dev packages.)

So, it'll all work fine if a further upload of boost 1.34 is not needed;
you'll have to disable creation of -dev packages in 1.34 if it is.

Summary of this mail:

  * please make the suggested changes on boost-defaults and come by for
    a final review.

Thanks for your work,

-- 
- Are you sure we're good?
- Always.
        -- Rory and Lorelai