[pkg-boost-devel] Upload of Boost 1.38

[Steve M. Robbins]

Hi Adeodato,

Thanks for the prompt response!  ;-)


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

> > If there's something for us Boost packagers to do in order
> > that Boost 1.38 be accepted into Debian, I'd really like to
> > know about it.
> 
> You can upload the ???boost1.38??? source package any time you want (which I
> guess will be as soon as possible, which is good, since if where???re
> going to do migration work, better do it against the latest version, so
> that it???ll last more).
>
> So, please upload boost1.38 to unstable at your earliest convenience,
> with versioned package names for libraries and -dev packages just like
> eg. boost1.37 has.

Oh, but the boost1.38 source was uploaded Feb 22 with versioned
package names as boost1.37 has.  I was asking whether it can be
accepted as-is or we need a new upload with something changed.


> > Naively, it seems like the same issue will reappear with the
> > boost-defaults package.  Let's say we upload boost-defaults with a
> > change from 1.38 to 1.39 and some packages fail to build against the
> > new version.  If I understand you right, the *build-deps* get a FTBFS
> > bug.  Wouldn't one such bug be enough to keep boost-defaults from
> > transitioning to testing?  If so, wouldn't that be enough to keep
> > boost1.39 from transitioning to testing?
> 
> No, boost1.39 (and, in fact, boost-defaults) would be able to migrate to
> testing on their own. Of course we???d have to keep an eye that packages
> remaind buildable on testing, but I think that???s manageable on our side.
> 
> Basically, painful migrations happen when a source package *drops*
> binary packages in order to introduce new ones. That is not the case
> here, so it???s not a problem.

OK.  Thanks for clearing up my confusion.  Now this proposal looks
even better, to me.


> I???d say let???s keep the ???2 versions in each suite??? objetcive
> as a goal, and make concessions later. Inevitable, sid and possibly
> testing is going to see more than two versions when new upstream
> releases happen, but that should be ideally temporary. If a
> migration is particularly tricky, we can make exceptions, okay?

I agree we can proceed on this basis and see how it works out.  


> 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
> 
>   * a mass bug filing for packages build-depending on versioned packages
>     to build-depend on the un-versioned ones instead
> 
>   * an automatic rebuild of those packages already build-depending on
>     the un-versioned ones (from Boost 1.34), and file bugs for those
>     that fail
> 
> I???m foreseeing this won???t be a cup of tea, but it???s something that has
> to be done just once. With a bit of luck, we???ll get rid of at least
> boost 1.34 and 1.35, and ideally 1.37 as well.

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?


Thanks,
-Steve
-------------- 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/20090321/db00779b/attachment.pgp