Graham Cobb wrote: > That is *very* disappointing. Afaiu it was clearly described and explained in the roadmap. If necessary I can try to find something which notes this.
> Presumably Diablo is the last update until 2009 at the earliest. I can't speculate about this. You'd have to consult a roadmap and I doubt that the roadmap includes dates. > More and more applications cannot be built for Maemo just > because they use features in glib introduced after 2.12.12. Personally I consider this a mistake of those programs. And I also believe you're wrong. A properly versioned operating system should be able to handle side by side libraries. Windows can do this, libssl can do it, and gecko can do it. Unix is supposed to be able to do it. If Debian can't (which it clearly can, see libssl), then that's a bug beyond the scope of maemo. > It should ONLY be a testing issue to make sure glib is kept up > to date in every release and it should be Nokia policy to keep > it up to date unless it is discovered to break an application. Please don't make assertions about such things. Especially if they involve resources you don't control. I understand that you're a customer, and therefore I hope you're paying something. But I'm sure Nokia has concerns about risk, compatibility, testing, stability, and ABI guarantees for all its customers, not just you. That said, to some extent people obviously do want to use later versions of libraries when/where possible. No one loves the idea of using code that's many years out of date with its ever growing set of known bugs. However sometimes bug-wise compatibility triumphs. > Don't forget: the community CANNOT update glib -- Nokia prevent that. The community may not be able to replace: /usr/lib/libgobject-2.0.so.0 /usr/lib/libgthread-2.0.so.0 /usr/lib/libglib-2.0.so.0 /usr/lib/libgmodule-2.0.so.0 However it could easily provide: /usr/lib/libgobject-2.0.so.0.1400.0 /usr/lib/libgthread-2.0.so.0.1400.0 /usr/lib/libglib-2.0.so.0.1400.0 /usr/lib/libgmodule-2.0.so.0.1400.0 (1400.0 is a random number, I believe the only number that's restricted is 1200.12.) If it felt like it. While this would mean you'd have multiple glibs on the system, it isn't impossible to do, and if you absolutely need it, you could do it. You could also provide /usr/maemo/lib/libgobject-2.0.so.0 /usr/maemo/lib/libgthread-2.0.so.0 /usr/maemo/lib/libglib-2.0.so.0 /usr/maemo/lib/libgmodule-2.0.so.0 And muck w/ ldconfig or do all sorts of other things if you really needed to (although you probably couldn't do this if you intended to use maemo-launcher, but I don't consider that such a big loss). And no. I'm not a DD, my advice does not constitute Debian advice. I'm a pragmatist and a hacker. If I need something, I make it work. I could easily void my warrantee by replacing glib as root from a package postinst (well, until someone takes away my postinst scripts). > So, sticking with an out of date glib stops the community providing some > applications. I'd be curious to see a list of applications that require newer glibs. That seems kinda strange to me. Note that this isn't just for me. Maintain a wiki page somewhere public, it'll help people when they try to argue for the next upgrade (do include the minimum required version if you can figure it out). Arguably this applies to any other package for which packages need newer versions. It's probably best to have a single page organized by package listing packages that need a newer version of the package and which version they need. > Alternatively (and maybe better), if Nokia aren't willing to > keep glib up to date they should rename it something else (nokiaglib) for > their own apps and let the community build and install up to date versions of > glib for community apps. *shrug* > > Diablo is not a new OS. > It is a new, updated, firmware installation. Barely. Ideally it would have been delivered via SSO. I'm not sure about the exact plans for when SSO goes live, for all I know (and I really don't know anything about it), it might. > Are you telling me that Nokia are actually testing that > applications built against diablo work on (unupgraded) > chinook systems? I'm pretty sure that people trying modest in the real world were doing just that. > Unless Nokia are testing that, there is a > danger that there is a change which has not been noticed > which means that some diablo applications do not work on chinook. (cd old-packages; ls |sort> /tmp/old-source-packages) (cd new-packages; ls |sort> /tmp/new-source-packages) diff -U0 /tmp/old-source-packages /tmp/new-source-packages|grep '^-[^-]'|perl -pne 's/-(\d+\.)*\d+(\+r\d+|)//;s/^-//' wc -l /tmp/old-source-packages About half of the packages have not changed version numbers at all. They may have changed minor versions (packages are retrieved weekly using apt-get source, and thus the default versioning is used for directories which is how old-packages / new-packages are generated). By this accounting, glib isn't listed, which means it "changed" (because its minor version changed). About 1/4 of the changed packages are l10n packages, which for all I know always get new versions (I don't pretend to understand how they operate, I think they have a single global version number for "localizing the world"). > I see no advantage at all to sharing a repository and a risk > (possibly small) that it will come back to bite us. The only reasons I see are space and convenience. Having actually dealt with having two live repositories which had integration rules, what worries me more is something where such rules exist. Either you have one repository or you have two, but trying to tie them together *is* a disaster. > I really don't see why anyone would bother to propose sharing > a repository -- certainly anyone who lived through > the mess of earlier point release Maemo updates. > Has that been tested? For a while the browser had both versions of libssl loaded because no one rebuilt one of the libraries we used to use the newer library. Nothing bad happened. The only complaint was memory bloat. Yes it really works. (again, I have minor concerns about what 0.9.7 means, but I still don't want to read the changelog.) > If so, that is good to know. It means that I don't > need to add a "diablo" distribution to my daily builds of GPE > for the GPE development team. > But it still doesn't convince me that there could not be > some other problem preventing diablo apps running on chinook. > > It does mean that the autobuilders should actually use chinook with > > repository access to diablo, otherwise the results will be > > things that aren't the most pleasant of experiences. > In general that doesn't work. Even if the autobuilder > continued to use the earlier SDK, it is possible that a > community-contributed library might use some feature from > the later release that would mean that a third app, which > links against the library, doesn't work on the earlier release. As long as the library it needs is available from one of the standard repositories, either the Nokia one or this one you guys are building (* I don't intend to push things to the autobuilder repository, so I'm excluding myself as I use "you guys"), and the package properly lists a versioned dependency, things will just work. > In this particular case, it might work. If we are lucky. > And if Nokia conduct sufficient testing. But why take the risk? > If we establish the principle now that every firmware update will > be reflected in a new repository, and the contents will be > autobuilt from the previous repository, This autobuilding thing is the complaint I mention above. It resulted in hell for us. It might be a great convenience for some people. But it will break some groups eventually. The browser team did not enjoy having to do very messy things to versions and releases just so that we could submit a package to one place while some secondary place automatically tried to use it and could reject our primary submission. > we eliminate those risks at virtually no cost to the community and a > considerable cost saving to Nokia (in testing). I don't see this. Please don't try to determine where and how Nokia costs are. I doubt most internals could give a reasonable estimate. But basically the maemo community run repository is up to the community, it can choose whichever rules it likes. It should be entirely independent of Nokia (rules, risk, and costs). > That is the big benefit the autobuilder gives us. Autobuilding may have advantages. However my experience with them is that they're very easy to do wrong and very hard to do right. I'll reserve judgement on your (*) autobuilder until after it's been deployed for 18 months and I can review all the complaints from your users. > In general, I would prefer that the autobuilder always uses > the correct SDK for the target release. -- The opinions expressed here, and in any other posts by me past, present, or future are my own unless otherwise noted. _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
