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
Attachment:
signature.asc
Description: Digital signature