[maemo-developers] Repositories mess: conclusions and actions
From: Nick Phillips nwp at nz.lemon-computing.comDate: Mon Nov 12 05:59:15 EET 2007
- Previous message: Repositories mess: conclusions and actions
- Next message: Repositories mess: conclusions and actions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 12/11/2007, at 1:03 PM, Graham Cobb wrote: > If a user does a dist-upgrade they will get both new libraries, so > no problem. > However, if the user installs an application which is built against > the new > libhildon1 (but which doesn't use libhildonfm2) then the AppMgr > will kindly > install the new libhildon1 without the new libhildonfm2. Which > would create > a configuration never tested by Nokia and could break existing > (Nokia-supplied and supported) applications which use libhildonfm2. > > Debian doesn't have this problem. The stable release is a single > unit and > doesn't get any upgrades (except security fixes, which are very > limited and > tested carefully). If a problem like the one I have described > occurs in the > testing release the affected user would log a bug or send a request > to a > mailing list or forum and (eventually) be told "this sort of thing > is a fact > of life using testing: just install the latest libhildonfm2". Well, I believe one of the reasons Debian requires the use of the latest libraries is to minimise the number of combinations of libraries that will be "out there" - if you don't build with the latest libraries then there will potentially be all sorts of (untested) combinations of libraries out there being used with the latest version of $my_shiny_app. If you do, then at least you can be sure that $my_shiny_app will work. Another reason is to ensure that the latest versions of the libraries will actually get some use - if new apps aren't built with them, then they'll end up in a stable release without having been adequately tested. Backports.org does follow the system that you suggest; in this case the versions of the libraries being used are likely to be fairly static, and they're not aiming to get new versions of anything tested. So I think it comes down to how you see the release process going. If you think it will predominantly be "here's a new app for the stable Maemo" then autobuilders should be building against the versions in that stable release. If you think it's going to be a moving target, with Nokia releasing new bits here and there, and everyone else releasing apps to run on whatever that latest is, then you need to follow a process more similar to Debian - probably with unstable & testing (where testing eventually becomes stable). It's even possible that we need a combination of both -- autobuilders for stable releases/non-current-hardware building with oldest libs, and autobuilders for latest-greatest building with latest libs. I think the biggest difference between e.g. Debian and Maemo is that some users of Maemo are going to be permanently stuck with old OS versions (on old hardware), and it's likely that app developers will still want their apps to run on them... and builds with latest libs will never percolate through to those users. > So, we need to ask Nokia what they want to do about this case. Indeed :-) Cheers, Nick
- Previous message: Repositories mess: conclusions and actions
- Next message: Repositories mess: conclusions and actions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]