Hello Adeodato et al., On Tue, Mar 10, 2009 at 09:31:39PM +0100, Adeodato Sim?? wrote: > 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? That's a great question. The answer is "it depends". Boost contains a large number of libraries, some of which (e.g. smart_ptr) are basically stable and haven't changed in years, while others are more of a work-in-progress and undergo API changes. So it depends on what part of boost a given package is using. As another data point: before we (the Debian Boost packaging team) adopted the strategy of multiple versions, I asked this question to the Boost list: In practice is there a large amount of work adapting existing client code to a new release? I'm asking in order to gauge whether it is useful for a linux distribution (Debian) to keep multiple versions of Boost available simultaneously; e.g. 1.34.1 and 1.35. Currently Debian provides only the latest version of Boost. c.f. http://lists.boost.org/Archives/boost/2008/03/135212.php That elicited 3 responses from library users: 1. Not if you can recompile the client code. Usually. 2. I have found that modifications, most minors, in user code are very common when switching boost version. 3. I think Debian (and other distributions) must keep multiple versions available. I'll count that as 2.5/3 responders suggesting that some level of source code modification is common when switching to a new Boost release. > If [no source changes are necessary for most boost-using packages], > 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. [...] > 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. I think it is a great adjunct to our initial proposal. I have had a couple of Debian package maintainers ask to keep the unversioned -devs precisely because they know that their package uses only the stable core of Boost (e.g. smart_ptr). Let me now ask you how transitions from sid to testing will work in this scenario. One of the biggest issues with our previous strategy of having a single boost source package is that boost (a) uses other complex libraries like ICU and now MPI, and (b) complex libraries like KDE use boost. So a new version of boost in sid often got entangled in transitions with other large packages like ICU, KDE, Qt, and the like, leading to a long delay before reaching testing. 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? You also propose a strategy of not updating boost-defaults immediately, but investigate locally the reverse deps to see how many fail to build. That sounds like a mechanism where we could upload boost1.39 and let it transition to testing while fixing all reverse deps that fail to build. Then update boost-defaults only after all rdeps are fixed. Is this a reasonable proposal, or would it be frowned upon? Note that one of our (unstated) goals is to get a new boost into debian testing without undue delay; i.e. without getting entagled in rdeps build problems. What would the release team recommend doing in the general case? > 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? I agree that this is a concern. To add to it, note that Boost adopted, about a year ago, a policy of quarterly releases and they have maintained that schedule in 2008. Boost 1.39 is due out on May 1. Keeping to just 2 Boost releases in Debian will be a challenge indeed. How do you feel about 3 or 4 releases (a year's worth)? > 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. I would suggest that the restriction to 2 versions of Boost would be a goal for Debian/stable rather than for sid. So in the scenario at hand, I'd upload 1.39 to sid and encourage the packages using 1.37 to port to 1.39 directly, skipping 1.38. I don't know how to do that without providing 1.39 in sid for them. If you want to be strict about 2 versions in sid, I guess you could remove 1.37 immediately after the 1.39 upload and really cause them FTBFS. I wouldn't choose the strict policy myself. As to the question of who will do the porting work, I'll be frank: it won't be me. I'll help out where I can, but I have a limited time for Debian each week and am already overstretched. I won't speak for the rest of the Boost team, except to note that the Changelog will show that for the past 7 years there has been only one active maintainer at a time, alternating between Domenico Andreoli and myself. There's not a lot of spare cycles here; help is more than welcomed! :-) I'm open to release team suggestions on how to keep boost to a reasonable number of versions, and what that reasonable number is. Clearly, the strategies will depend on how much breakage is encountered in a typical Boost relase. As indicated, I don't have a good handle on this. I think that your proposal of boost-defaults -- especially the strategy of locally trying to build rdeps -- will help to answer this question in the context of Debian packages. So that seems to me to be a good way forward. Cheers, and thanks for engaging on this, -Steve
Attachment:
signature.asc
Description: Digital signature