[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Upload of Boost 1.38

* Steve M. Robbins [Sun, 22 Feb 2009 21:25:39 -0600]:

> Hi,

Hello, Steve, sorry for the very late reply.

In principle, I think having two boost versions in the archive is
reasonable, particularly if the API is known to change often and porting
to a new boost version is a significant effort that will have to happen
preferably upstream. I’m sure you’re aware, however, that with your
recent upload we’ll be at 4 boost versions in unstable! (But shouldn’t
be a worry, since we’re very early in the development cycle.)

I have a couple concerns with your proposal, though. Let me start the
first of these with a question: given a new version of boost, eg. 1.38,
how likely is it that a package will rebuild just fine against this new
version? In other words, what percentage of packages are expected to
rebuild without changes? If I look at your mail:

> Hopefully, the transition is as easy as changing the Build-Depends
> line and recompiling.

If that is going to be the case, the need for sourceful uploads should
be minimized. For that, I’m going to recommend that you adopt for boost
the common idiom in Debian for these situations, a "boost-defaults"
source package. It’s quite likely you’ll be familiar with the idea, but
let me explain nevertheless.

The point is that packages should build-depend on an unversioned package
name, like the existing libboost-date-time-dev or libboost-regex-dev
packages. These are to be dummy packages provided by the boost-defaults
source package, and just depend on the most recent version of said
libraries, eg. libboost-date-time1.38-dev and libboost-regex1.38-dev
(which are to be provided by the boost1.38 source package). 

So, say we’d have all of the archive build-depending on the unversioned
names and built against boost 1.38, and then boost 1.39 comes along and
gets uploaded as boost1.39. After which, boost-defaults gets uploaded¹
to point the unversioned names to the 1.39 versions, and then,a Bin-NMU
campaign can begin.

In the best scenario, no package fails to build against boost 1.39, and
boost 1.38 can be removed right away. Of course, we all know that’s not
going to happen: there are failures, for which bugs at RC severity will
be filed. Now, each of these bugs is very easily fixable by just going
back and build-depending on libboost-date-time1.38-dev, etc., instead of
the unversioned names. Or, with a bit of poking, maybe porting is
trivial, or a new upstream version exists, etc.

Note that, of course, we’re trading severity:important bugs (“Please
update your package to boost1.39”) for severity:serious ones (“Your
package FTBFSes with the boost in unstable”), which is a trade-off to
consider very carefully. I think it’s worth it if the number of RC bugs
is going to be small. But let me tell you, if we go with the
severity:important bugs, I’m pretty sure you (the boost maintainers)
will have to do a lot of NMUing to meet your “only 2 boost versions in
the archive” objective.

Additionally, we can just be smart and not bump boost-defaults to point
at the new version immediately after it’s uploaded to unstable. You
could (or ask Lucas to) rebuild all reverse-dependencies with a local
version of the new boost-defaults, and see how many fail, and agree with
us (the Release Team) what to do next. (I say agree with us, because
depending on the stage of the development cycle, and/or the state of
unstable, it may be wiser to do one thing or the other.)

So, please let me know what you think of this recommendation, particularly
if you can think of any reasons it would be less appropriate than your
initial proposal.

My second concern is related to the objective of keeping only two boost
versions in the archive (well, in testing/unstable). As I said, this is
a very desirable objective, and I’d really appreciate if we would not
let it slip. When thinking about reasons why it could slip, it
immediately comes to mind the situation where you have, say, boost 1.37
and boost 1.38 in the archive, with most packages using 1.38 but a
handful still at 1.37. Then boost 1.39 gets released and... what do you
do? The interesting point is that those packages at 1.37 were not
updated to 1.38 for a reason, most likely that they required porting and
upstream was not ready. What if that’s still the case?

Here, we mostly need your expertise in the area to determine how
feasible it would be to just do the work of porting those apps to 1.38
or even better 1.39, and if you think it is acceptable for you not
uploading (to follow with our example) 1.39 to unstable until all 1.37
applications have patches porting them to either 1.38 or (preferably)
1.39, and if you’re volunteering to do the porting job, or help the
maintainers do it themselves with a bit of help.

So, bottom line:

  * any reasons not to adopt the boost-defaults scheme?
  * what will be your commitments to ensure the “only 2 boost versions
    in the archive” objective is met?

Thanks in advance, and again, apologies for the delay in getting back to
you, were a bit too backlogged at the moment.


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

Reply to: