Re: Backwards compatibility broken PR1.1 SDK
On Jan 21, 2010, at 3:54 PM, Yves-Alexis Perez wrote: > On 21/01/2010 11:46, Jeremiah Foster wrote: >>> For software and tools I agree. But processes will be very different. >>> Maemo is not aiming for a release every 18 months, Debian is. >> The "official" release time period is 24 months. >> > > There's no “time-based” release planned at all. What's planned (and for > the moment not yet done) is “time-based” freezes, which is not the same > thing. Debian releases ”when it's ready” (and usually late). According to the DPL's talk last year at FOSDEM, there in fact is an informal time period between releases with a goal of 18 months and a maximum of 24 months. Both Etch and Lenny were within this time frame coming in at 22 months - so they weren't late. :-) Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
On 21/01/2010 11:46, Jeremiah Foster wrote: >> For software and tools I agree. But processes will be very different. >> Maemo >> > is not aiming for a release every 18 months, Debian is. > The "official" release time period is 24 months. > There's no “time-based” release planned at all. What's planned (and for the moment not yet done) is “time-based” freezes, which is not the same thing. Debian releases ”when it's ready” (and usually late). Cheers, -- Yves-Alexis ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
On Jan 21, 2010, at 1:35 AM, Graham Cobb wrote: > On Wednesday 20 January 2010 21:50:02 Jeremiah Foster wrote: >> I disagree. Debian has very high quality packages and software. > > I don't think we are disagreeing. I am saying Debian is geared to stability > and quality. I am just making the point that it achieves that by forcing > things to take a long time to proceed through the QA process and severely > restricting the number of packages that are accepted (I know Debian has > **lots** of packages but nothing like the number of apps the iPhone has and > new packages are not being added at anything like the rate any commercial > AppStore accepts them -- those are the goals for us). Not sure about that, debian has maybe 27,000 packages in the stable distro, plus several thousand more in testing. Plus they manage tens of thousands more in volatile, non-free, and unstable. Not to mention backports or Ubuntu, or Mepis, etc. So I think a fairly reasonable estimate is in the neighborhood of 100,000 packages for debian and debian-like systems. Note that these packages are of diverse programming languages (iPhone apps are mostly Objective C), and that the debian packages do different things. Apple has dozens of apps that do the same thing, pdf readers, noise makers, girls-in-bikinis apps, etc. Apple is no where near as diverse and large as they market themselves to be. Besides, lots of the "apps" on the iPhone are built-in on the N900; skype anyone? Comparing the two is really Apples and oranges, though I understand your point; Maemo has fewer commercial apps than the iPhone and Android. > >> Actually not true. Debian has had security for testing for about four and a >> half years. >> http://lists.debian.org/debian-devel-announce/2005/09/msg6.html > > Security yes. Support no. What support is missing? Debian has always relied on the community to support the OS. > >> I think you are referring to unstable here. I run testing everywhere, even >> production web servers, and I have few problems. Especially compared to the >> Ubuntu machines I admin, or for that matter, fedora. > > No, I meant testing. I also use testing. But people like you, me and the > members of this mailing list are not the target audience for Maemo. For > example, kde is currently severely broken in testing -- it has been for many > months and will continue to be for some time yet. Okay, I concede this point, you're right. > >> I think debian should server as a model for maemo, after all, Nokia based >> its OS on debian. The biggest problem is Nokia's penchant for separating >> their releases from the community. There really should be greater >> cooperation between the community and Nokia, it is pretty much as simple as >> that. > > For software and tools I agree. But processes will be very different. Maemo > is not aiming for a release every 18 months, Debian is. The "official" release time period is 24 months. > That fundamental > difference stops the processes being at all similar. > > By all means see what we can learn from Debian (and Ubuntu and Fedora and > ...) > but we have to acknowledge that different goals will require different > processes. True enough, but greater co-operation should help facilitate whatever release goals we have. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
On Jan 21, 2010, at 1:35 AM, Graham Cobb wrote: > On Wednesday 20 January 2010 21:50:02 Jeremiah Foster wrote: >> I disagree. Debian has very high quality packages and software. > > I don't think we are disagreeing. I am saying Debian is geared to stability > and quality. I am just making the point that it achieves that by forcing > things to take a long time to proceed through the QA process and severely > restricting the number of packages that are accepted (I know Debian has > **lots** of packages but nothing like the number of apps the iPhone has and > new packages are not being added at anything like the rate any commercial > AppStore accepts them -- those are the goals for us). Not sure about that, debian has maybe 27,000 packages in the stable distro, plus several thousand more in testing. Plus they manage tens of thousands more in volatile, non-free, and unstable. Not to mention backports or Ubuntu, or Mepis, etc. So I think a fairly reasonable estimate is in the neighborhood of 100,000 packages for debian and debian-like systems. Note that these packages are of diverse programming languages (iPhone apps are mostly Objective C), and that the debian packages do different things. Apple has dozens of apps that do the same thing, pdf readers, noise makers, girls-in-bikinis apps, etc. Apple is no where near as diverse and large as they market themselves to be. Besides, lots of the "apps" on the iPhone are built-in on the N900; skype anyone? Comparing the two is really Apples and oranges, though I understand your point; Maemo has fewer commercial apps than the iPhone and Android. > >> Actually not true. Debian has had security for testing for about four and a >> half years. >> http://lists.debian.org/debian-devel-announce/2005/09/msg6.html > > Security yes. Support no. What support is missing? Debian has always relied on the community to support the OS. > >> I think you are referring to unstable here. I run testing everywhere, even >> production web servers, and I have few problems. Especially compared to the >> Ubuntu machines I admin, or for that matter, fedora. > > No, I meant testing. I also use testing. But people like you, me and the > members of this mailing list are not the target audience for Maemo. For > example, kde is currently severely broken in testing -- it has been for many > months and will continue to be for some time yet. Okay, I concede this point. > >> I think debian should server as a model for maemo, after all, Nokia based >> its OS on debian. The biggest problem is Nokia's penchant for separating >> their releases from the community. There really should be greater >> cooperation between the community and Nokia, it is pretty much as simple as >> that. > > For software and tools I agree. But processes will be very different. Maemo > is not aiming for a release every 18 months, Debian is. The "official" release time period is 24 months. > That fundamental > difference stops the processes being at all similar. > > By all means see what we can learn from Debian (and Ubuntu and Fedora and > ...) > but we have to acknowledge that different goals will require different > processes. True enough, but greater co-operation should help facilitate whatever release goals we have. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
ext Graham Cobb writes: > I *think* that, here in Maemo, we are trying to create a model with > different goals from any of the other distributions, so our decisions may > also be different, but I certainly want us to learn from other experience. I wouldn't put it as "different goals", but with "additional goals". One additonal goal of Maemo is to support 3rd party development in a better integrated way than Debian and other distributions do. Debian does of course support 3rd party developers: they stick to standards like FHS and LSB and they are generally not screwing over 3rd party applications (unlike the Linux kernel does with out-of-tree drivers, for example). Maemo tries to integrate '3rd party' developers more tightly into the distribution, by offering processes and infrastructure for them (maemo.org) and platform support (Appmanager pointing to maemo.org by default, more user friendly view of packages). But that's an addition to what Debian and other Linux distributions do, and not in conflict with it. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
On Wednesday 20 January 2010 21:50:02 Jeremiah Foster wrote: > I disagree. Debian has very high quality packages and software. I don't think we are disagreeing. I am saying Debian is geared to stability and quality. I am just making the point that it achieves that by forcing things to take a long time to proceed through the QA process and severely restricting the number of packages that are accepted (I know Debian has **lots** of packages but nothing like the number of apps the iPhone has and new packages are not being added at anything like the rate any commercial AppStore accepts them -- those are the goals for us). > Actually not true. Debian has had security for testing for about four and a > half years. > http://lists.debian.org/debian-devel-announce/2005/09/msg6.html Security yes. Support no. > I think you are referring to unstable here. I run testing everywhere, even > production web servers, and I have few problems. Especially compared to the > Ubuntu machines I admin, or for that matter, fedora. No, I meant testing. I also use testing. But people like you, me and the members of this mailing list are not the target audience for Maemo. For example, kde is currently severely broken in testing -- it has been for many months and will continue to be for some time yet. > I think debian should server as a model for maemo, after all, Nokia based > its OS on debian. The biggest problem is Nokia's penchant for separating > their releases from the community. There really should be greater > cooperation between the community and Nokia, it is pretty much as simple as > that. For software and tools I agree. But processes will be very different. Maemo is not aiming for a release every 18 months, Debian is. That fundamental difference stops the processes being at all similar. By all means see what we can learn from Debian (and Ubuntu and Fedora and ...) but we have to acknowledge that different goals will require different processes. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
On Jan 20, 2010, at 18:24, Graham Cobb wrote: > On Wednesday 20 January 2010 16:32:23 Jeff Moe wrote: >> For what it's worth, in the Fedora buildsystem (Koji), the buildsystem is >> running with the latest updates. Perhaps investigating what the various >> other distros do (especially Debian) and doing what they do would be a good >> approach (if they have mostly all settled on similar approaches). > > Jeff, thanks for the input -- we certainly need to take a look at what other > projects do. > > I am most familiar with Debian. There the challenge is very different. > Debian, like many distributions, is geared to creating periodic releases > containing a consistent set of packages. It chooses to maximise stability > and, to some extent, quality by sacrificing time to release and, to some > extent, openness (only DD's can submit packages). I disagree. Debian has very high quality packages and software. Part of debian's success is its rigorous QA procedures. There is puiparts, lintian, and a considerable period of software traveling through testing which makes debian software high quality. Plus a good deal of packaging is done through teams so there are lots of eyes on packages. Debian also has a concept of "release critical" bugs and won't release until they are all gone. That is a commitment to quality that commercial operating systems cannot match - they have to meet sales goals and timetables. Yes only DDs can upload packages to the ftp server. But even there the ftpmasters look at packages and check them before they go into the distribution. Anyone can join one of the packaging teams and submit a package into a debian subversion or git repo. I have contributed many packages over the years and am not a DD, nor do I feel the need to be one since I can get the software I want into debian so easily. It isn't really fair to say that Debian lacks openness. > The consistent and tested > set of packages are then not touched (apart from critical security patches) > for the next 18 months or so while the next release is prepared. That is not > the model the Maemo community members want as they want to be able to create > and launch new applications and new versions of applications in days, not > months. > > Debian testing is closer to the release goals of Maemo (although still quite > far away -- it takes a long time for something to propagate into testing and > relatively few new packages are added). But Debian testing requires frequent > updates of all parts of the system, and no guarantees of support. Actually not true. Debian has had security for testing for about four and a half years. http://lists.debian.org/debian-devel-announce/2005/09/msg6.html > The Debian > community is very clear that only people who can tolerate occasional broken > systems, and continuous change, should install testing. I think you are referring to unstable here. I run testing everywhere, even production web servers, and I have few problems. Especially compared to the Ubuntu machines I admin, or for that matter, fedora. > > As each project has different goals, and constraints, the decisions made > around process (including how builds and repositories work, who can submit > code, how QA works, etc.) are going to be very different. But suggestions or > comments from people familiar with how other projects work are certainly > welcome. I *think* that, here in Maemo, we are trying to create a model with > different goals from any of the other distributions, so our decisions may > also be different, but I certainly want us to learn from other experience. I think debian should server as a model for maemo, after all, Nokia based its OS on debian. The biggest problem is Nokia's penchant for separating their releases from the community. There really should be greater cooperation between the community and Nokia, it is pretty much as simple as that. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
On Jan 20, 2010, at 17:32, Jeff Moe wrote: >> Can we, like with the opt problem, come to a solution with >> community power[tm]? > > For what it's worth, in the Fedora buildsystem (Koji), the buildsystem is > running with the latest updates. Perhaps investigating what the various other > distros do (especially Debian) and doing what they do would be a good > approach (if they have mostly all settled on similar approaches). I have stated my preference for the debian build tools previously and would like to state that here again. I think a debian-based build system would be more stable than the collection of python scripts we use now and would have the extra benefit of being tested and maintained upstream. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
On Wednesday 20 January 2010 16:32:23 Jeff Moe wrote: > For what it's worth, in the Fedora buildsystem (Koji), the buildsystem is > running with the latest updates. Perhaps investigating what the various > other distros do (especially Debian) and doing what they do would be a good > approach (if they have mostly all settled on similar approaches). Jeff, thanks for the input -- we certainly need to take a look at what other projects do. I am most familiar with Debian. There the challenge is very different. Debian, like many distributions, is geared to creating periodic releases containing a consistent set of packages. It chooses to maximise stability and, to some extent, quality by sacrificing time to release and, to some extent, openness (only DD's can submit packages). The consistent and tested set of packages are then not touched (apart from critical security patches) for the next 18 months or so while the next release is prepared. That is not the model the Maemo community members want as they want to be able to create and launch new applications and new versions of applications in days, not months. Debian testing is closer to the release goals of Maemo (although still quite far away -- it takes a long time for something to propagate into testing and relatively few new packages are added). But Debian testing requires frequent updates of all parts of the system, and no guarantees of support. The Debian community is very clear that only people who can tolerate occasional broken systems, and continuous change, should install testing. As each project has different goals, and constraints, the decisions made around process (including how builds and repositories work, who can submit code, how QA works, etc.) are going to be very different. But suggestions or comments from people familiar with how other projects work are certainly welcome. I *think* that, here in Maemo, we are trying to create a model with different goals from any of the other distributions, so our decisions may also be different, but I certainly want us to learn from other experience. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
On Monday 18 January 2010 18:08:33 Niels Breet wrote: > Hi, > > I've been discussing this issue with some people before as hypothetical > case, but now it seems that we run into it: Compiling an application > against the PR1.1 SDK creates packages which can not be installed on > earlier firmware releases. > > In this case we have have a libosso version which is higher than the > one in previous releases. As this dependency gets automatically added > when compiling in the PR1.1 SDK this poses a problem. > > The autobuilder uses the repository.maemo.org repository, so it > automatically uses newer packages when they are available. > > For Extras this means that install of an application which is compiled > against the new SDK fails without any description we can expect an > end-user to understand. This is something which should be prevented. > > How can we work around this problem: > > 1: Only compile against the original SDK. >This prevents new features from ever be available to developers, >but should work until there is real API/ABI breakage in a new >firmware. > > 2: Use version specific repositories >This needs Application Manager support as we need to fetch from a >separate repository every time. Also requires us to build against >every sdk version known to man. > > 3: Depend on >= mp-fremantle-generic-pr | maemo-version >We would need a hack in the autobuilder to add depends to pr and >maemo version. This way a user needs to upgrade to at least the >required firmware image. I think this will make it easier for an >end-user to understand what is happening. > >We could, with help of the AM team, even detect in the AM that >a firmware upgrade is required and give a the end user a nice >warning/description. > > Currently the AM doesn't have any means to detect which firmware > version a package requires. Option 3 solve that issue at the same > time. > > If you have an alternative solution on how to go about fixing this > issue, then please let me know. > > Can we, like with the opt problem, come to a solution with > community power[tm]? For what it's worth, in the Fedora buildsystem (Koji), the buildsystem is running with the latest updates. Perhaps investigating what the various other distros do (especially Debian) and doing what they do would be a good approach (if they have mostly all settled on similar approaches). -Jeff (goes back to lurking on this thread) http://wiki.maemo.org/User:Jebba ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
Hi, Stoppa Igor (Nokia-D/Helsinki) wrote: This really isn't hard! For the vast majority of applications there is no reason at all why they cannot be built against the first software release and install on all later releases, taking advantage of the bug fixes made since. I have been doing that for GPE since the first Maemo release. That is what the autobuilder should be doing by default -- no need to make life hard for users **by default**! Building is not so much my concern, but rather testing: what is going to be the accepted environment for approving and releasing a new version of your sw? Hopefully not the first sales release. Although SW would be built against the shared libraries from the initial release, they should of course be tested against the latest release. If the software doesn't work in the latest release because minor Maemo update broke binary _backwards_ compatibility in some library, only then it needs a separate build (also) for latest release SW libraries. One of the problems is that we don't have any automated thing that would report about ABI incompatibilities between shared library version. This would also tell developers who've integrated an application to first release, to build and check it against a latest one because it had a binary incompatible change for one of their direct dependencies. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
ext Graham Cobb writes: > It is still my view that, if at all possible, applications should install on > the initial release. Yes, this is very important. [ Still, it is also important to give good guidance to the user when it does have in fact to update the OS before he can install a certain application. But let's concentrate on your point here. ] You propose to achieve this by building (most) applications in the SDK that has been released with the initial release. This means that the build environment for (the majority of) applications will not be updated and we have no good way to fix bugs in it. This is a very high price to pay, IMO. The build environment will not be updated since the SDK releases done by Nokia are not able to produce applications that can be installed on older OS releases. And this is the real problem that we should attack: We (Nokia) needs to make SDK releases that produce applications that can be installed on older OS releases, unless they really do in fact need features that are only available in a newer OS release. This is the next step in Maemo's path to distribution enlightenment. Maybe it comes a bit late, but better late than never. The primary mechanism at work is Debian's 'shlibdeps' machinery. This machinery determines how the dependencies look that applications acquire at build time. We (Nokia) need to master this machinery much better than we do now. man dpkg-shlibdeps man dh_makeshlibs man dh_shlibdeps First, we can analyze the package.shlibs files in a SDK release to see building against which packages will require newer OS releases than the previous SDK release. If we are not happy with what we find, we can reject that SDK release. (Of course, this analysis should be done continously and not only once we have a release.) Second, we need to seriously work towards producing 'better' package.shlibs files, and to start using package.symbols files. Ideally, there shouldn't be any 'accidental' dependencies: If a executable in package-A links against a library in package-b, then package-a should depend on "package-b (>= VER)" where VER is the lowest version of package-b that has all the symbols that package-a actually uses. This can be achieved with package.symbols files. man dpkg-gensymbols A compromise to using dpkg-gensymbols is to manually pass a good value to the -V option of dh_makeshlibs. This is the least we should aim for. > All we need is an exception process for the very, very few apps which > want to make use of the few new features introduced in the new > releases. That is why I proposed the alternate builder queues which > will cause the builder to use a later SDK. Any application built > using one of the alternate queues will not install on all versions of > Fremantle so using it is discouraged unless it is necessary. This will work, but it would be a testament to our (Nokias) incompetence of making good SDK releases. I hope we can avoid that. But it is certainly an option, if only temporarily. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
ext Graham Cobb wrote: It is still my view that, if at all possible, applications should install on the initial release. Otherwise we lose those applications for a large part of our user base (those who got a device with an earlier version of the software and have not upgraded). this is the point where we disagree: _at_the_moment_ your user base might be using the earlier version of the sw, but even if none of them was to update, the proportion are going to change in the future, hence my proposal below For example, what about actively supporting (at any point in time) the current and previous official build? That should cover the vast majority of the users and ensure that you do not deal constantly with bugs that have already been fixed. I don't object to applications rejecting bugs (and even a Maemo policy which says that bug reports will be rejected) if the device is not running the latest or previous firmware. But that is different from building them such that they will not install on previous versions. I didn't mean that, just what you said, actively support only recent sw. This really isn't hard! For the vast majority of applications there is no reason at all why they cannot be built against the first software release and install on all later releases, taking advantage of the bug fixes made since. I have been doing that for GPE since the first Maemo release. That is what the autobuilder should be doing by default -- no need to make life hard for users **by default**! Building is not so much my concern, but rather testing: what is going to be the accepted environment for approving and releasing a new version of your sw? Hopefully not the first sales release. All we need is an exception process for the very, very few apps which want to make use of the few new features introduced in the new releases. I think the impact of new features varies greatly depending on the POV. Graphics is a very good example: if an application doesn't rely on OpenGL or QT, then it's no problem. But for a vast class of applications there will be a significant difference. That is why I proposed the alternate builder queues which will cause the builder to use a later SDK. Any application built using one of the alternate queues will not install on all versions of Fremantle so using it is discouraged unless it is necessary. Yes, I think we mostly agree, it's just the expectations/forecast about future applications development that are different. igor ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
On Wednesday 20 January 2010 10:34:53 Igor Stoppa wrote: > Hi, > > ext Graham Cobb wrote: > > We have to live with that and try to come up with a solution that is best > > for the users. In my view, that means having as many apps as possible > > available to people who are still running the initial release. > > That would not be very wise: you are assuming that all the units will be > manufactured with the same SW onboard. No I'm not -- I am well aware that Nokia will be updating the factory firmware. But that is no problem: any application which supports the initial release will also continue to work on all the later releases, at least until Harmattan. It is still my view that, if at all possible, applications should install on the initial release. Otherwise we lose those applications for a large part of our user base (those who got a device with an earlier version of the software and have not upgraded). > For example, what about actively supporting (at any point in time) the > current and previous official build? > That should cover the vast majority of the users and ensure that you do > not deal constantly with bugs that have already been fixed. I don't object to applications rejecting bugs (and even a Maemo policy which says that bug reports will be rejected) if the device is not running the latest or previous firmware. But that is different from building them such that they will not install on previous versions. This really isn't hard! For the vast majority of applications there is no reason at all why they cannot be built against the first software release and install on all later releases, taking advantage of the bug fixes made since. I have been doing that for GPE since the first Maemo release. That is what the autobuilder should be doing by default -- no need to make life hard for users **by default**! All we need is an exception process for the very, very few apps which want to make use of the few new features introduced in the new releases. That is why I proposed the alternate builder queues which will cause the builder to use a later SDK. Any application built using one of the alternate queues will not install on all versions of Fremantle so using it is discouraged unless it is necessary. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
Hi, ext Graham Cobb wrote: We have to live with that and try to come up with a solution that is best for the users. In my view, that means having as many apps as possible available to people who are still running the initial release. That would not be very wise: you are assuming that all the units will be manufactured with the same SW onboard. But what gets flashed in production gets updated every now and then, when a new SW build is available. This is a typical procedure and is aimed at: - reducing failure rate in production caused by sw bugs - reducing return rate and customer care costs in the field when users do not update the sw and complain about bugs already fixed So I recommend a different approach. For example, what about actively supporting (at any point in time) the current and previous official build? That should cover the vast majority of the users and ensure that you do not deal constantly with bugs that have already been fixed. igor ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
On Jan 19, 2010, at 15:20, Michael Cronenworth wrote: > The user will be told why they can't update their little fart app. We don't have fart apps in Maemo. You're thinking of the iPhone. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
Graham Cobb on 01/19/2010 05:08 AM wrote: We have to live with that and try to come up with a solution that is best for the users. In my view, that means having as many apps as possible available to people who are still running the initial release. This should be noted as a failure of Nokia to produce an open device. I suppose I was too optimistic in thinking all N900s that have third-party applications installed have access to the Internet and would update all software when the device told them updates are available. Perhaps the SSU (or whatever the acronym is) should be updated to not list or allow any third party updates when Nokia pushes a major update. After all I've said, I still believe option 3 is the best option. Building multiple packages for Maemo 5 is a ridiculous solution. If someone is still running 2009-42-1 and it's the year 2011 and they want to install a third party app with a lib dep on a 2010-12-1 update, then SSU will not let the update happen due to the dep. The user will be told why they can't update their little fart app. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
On Monday 18 January 2010 22:50:51 Michael Cronenworth wrote: > Graham Cobb on 01/18/2010 04:42 PM wrote: > > I do think there may be an option 1.5: > > Turning Linux into Windows shouldn't be a project goal of Maemo. I don't understand your comment, Michael, but note that the reason we have a problem here is because Nokia have put in place mechanisms that prevent an application installation from updating just the component packages it needs. So, users get software in whole "releases" and will be unwilling to upgrade their "release" just to install an application. We have to live with that and try to come up with a solution that is best for the users. In my view, that means having as many apps as possible available to people who are still running the initial release. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
On Tuesday 19 January 2010 08:17:25 David Greaves wrote: > Graham Cobb wrote: > > I do think there may be an option 1.5: create multiple autobuilder queues > > which feed the same repository but build against different SDK releases. ... > > I like - but as someone mentioned to me in a similar situation: testing. > > We'd need testers for each queue and that may be tricky. Do we? I have a goal that all applications install on as many releases as possible and only use a restricted version queue if they **really** have to. I don't want to create processes that give developers incentives to use a restricted queue -- quite the opposite. The tradeoff is that that means that many applications will not be able to have been tested against all the possible releases they might see. But this is very little different from an application being out there when a new release happens. Otherwise we will find that many applications are just not available to most of our users. I predict that by the time Maemo 6 ships, half of all N900's sold will still be running the release that shipped from the factory. Anyone got any data? Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
Graham Cobb wrote: > I do think there may be an option 1.5: create multiple autobuilder queues > which feed the same repository but build against different SDK releases. For > example, a "fremantle" queue which builds against the base release (for > ever), and a "fremantle-pr1.1" queue which builds against the new SDK (for > ever), but both populate the same repository (extras-devel fremantle). That > would allow the applciation developer to decide which users they are willing > to support. If the application supports all fremantle users it submits to > the fremantle queue. But if it uses a new feature (or even an important bug > fix) from the pr1.1 release the maintainer could submit it to the > fremantle-pr1.1 queue. > > If we did this, I wouldn't object to automatically adding a dependency on the > device software version, as long as it is worked out from which queue you > submit to. I like - but as someone mentioned to me in a similar situation: testing. We'd need testers for each queue and that may be tricky. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
Graham Cobb on 01/18/2010 04:42 PM wrote: I do think there may be an option 1.5: Turning Linux into Windows shouldn't be a project goal of Maemo. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
On Monday 18 January 2010 21:08:33 Niels Breet wrote:
> I've been discussing this issue with some people before as hypothetical
> case, but now it seems that we run into it: Compiling an application
> against the PR1.1 SDK creates packages which can not be installed on
> earlier firmware releases.
The problem isn't really new: we have had it with all Maemo releases in the
past. For versions 1-3 it was something the developer had to handle
themselves, for version 4 it impinged on the autobuilder and is one reason we
insisted on a new name ("Diablo") for the release after Chinook, so it was
easy to build different versions (although, in fact, binaries built on
Chinook normally run perfectly well on Diablo).
For GPE I still build against Maemo 2, Maemo 3 and Maemo 4 and, in each case,
I use the SDK from the .0 release to build binaries which will run on any .*
release.
> The autobuilder uses the repository.maemo.org repository, so it
> automatically uses newer packages when they are available.
A particular autobuilder queue name should always use a fixed SDK release,
with contents which never change. That is what the "queue name" really
means, in my opinion.
> 1: Only compile against the original SDK.
>This prevents new features from ever be available to developers,
>but should work until there is real API/ABI breakage in a new
>firmware.
This should be the answer for "small" releases (like we have here). Just in
case anyone is confused, in most cases building against an old library does
**not** mean that running with a new version is prevented: so bug fixes in
newer releases of libraries work fine. The only thing this option prevents
is using a new **feature** (in particular, a new function call) in the new
library which was not in the old library.
> 2: Use version specific repositories
>This needs Application Manager support as we need to fetch from a
>separate repository every time. Also requires us to build against
>every sdk version known to man.
For "larger" releases (in particular, ones with new features in libraries
which developers may want to use), the release should be given a new name and
a new repository and a new autobuilder queue should be created. If backwards
compatability is expected, it would be feasible to populate the new
repositories (extras, extra-testing and extras-devel) by just copying the
packages from the previous release but new versions of the packages could be
built to use the updated libraries if they wished.
> 3: Depend on >= mp-fremantle-generic-pr | maemo-version
>We would need a hack in the autobuilder to add depends to pr and
>maemo version. This way a user needs to upgrade to at least the
>required firmware image. I think this will make it easier for an
>end-user to understand what is happening.
I don't like this. We should not have an application forcing a maemo software
upgrade. Different people will have very different tolerance to doing
software upgrades (most of us developers and power users are keen to try new
releases, but most ordinary users will resists as long as possible).
It certainly can't be the case that just building after the new release has
been shipped means your users have to upgrade. If I have thousands of users,
I need to be able to ship new releases to them without forcing an upgrade.
Don't forget that upgrades are not even available to all users at the same
time (today we have the Vodafone problem, which will only get worse in future
with different operator versions and different country versions available at
different times).
I do think there may be an option 1.5: create multiple autobuilder queues
which feed the same repository but build against different SDK releases. For
example, a "fremantle" queue which builds against the base release (for
ever), and a "fremantle-pr1.1" queue which builds against the new SDK (for
ever), but both populate the same repository (extras-devel fremantle). That
would allow the applciation developer to decide which users they are willing
to support. If the application supports all fremantle users it submits to
the fremantle queue. But if it uses a new feature (or even an important bug
fix) from the pr1.1 release the maintainer could submit it to the
fremantle-pr1.1 queue.
If we did this, I wouldn't object to automatically adding a dependency on the
device software version, as long as it is worked out from which queue you
submit to.
Graham
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Backwards compatibility broken PR1.1 SDK
Niels Breet on 01/18/2010 03:08 PM wrote: Can we, like with the opt problem, come to a solution with community power[tm]? An SONAME change during a distribution version's lifetime is quite nasty. Most, if not all, distributions frown upon such a thing. I'm surprised that this was done, given the locked down state of some Brainstorm ideas. I realize that sometimes it is unavoidable, but a e-mail to the maemo-developers list would have been helpful. More communication the better. :) The proper way to handle it would be option 3. The Maemo build system should be able to perform "Broken Dependency" checks daily (or upon your request) to insure a stateful system. An e-mail[1] to maemo-developers (or the appropriate list) should be sent that lists the broken packages. If there are packages that were built against an older SONAME, a Maemo or Nokia member should rebuild those packages and file bugs with the project if a rebuild fails. The package release number should be incremented and a changelog entry that defines "Rebuild for $LIBRARY_NAME change" should be added. [1] http://lists.fedoraproject.org/pipermail/test/2010-January/087997.html ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Backwards compatibility broken PR1.1 SDK
Hi, I've been discussing this issue with some people before as hypothetical case, but now it seems that we run into it: Compiling an application against the PR1.1 SDK creates packages which can not be installed on earlier firmware releases. In this case we have have a libosso version which is higher than the one in previous releases. As this dependency gets automatically added when compiling in the PR1.1 SDK this poses a problem. The autobuilder uses the repository.maemo.org repository, so it automatically uses newer packages when they are available. For Extras this means that install of an application which is compiled against the new SDK fails without any description we can expect an end-user to understand. This is something which should be prevented. How can we work around this problem: 1: Only compile against the original SDK. This prevents new features from ever be available to developers, but should work until there is real API/ABI breakage in a new firmware. 2: Use version specific repositories This needs Application Manager support as we need to fetch from a separate repository every time. Also requires us to build against every sdk version known to man. 3: Depend on >= mp-fremantle-generic-pr | maemo-version We would need a hack in the autobuilder to add depends to pr and maemo version. This way a user needs to upgrade to at least the required firmware image. I think this will make it easier for an end-user to understand what is happening. We could, with help of the AM team, even detect in the AM that a firmware upgrade is required and give a the end user a nice warning/description. Currently the AM doesn't have any means to detect which firmware version a package requires. Option 3 solve that issue at the same time. If you have an alternative solution on how to go about fixing this issue, then please let me know. Can we, like with the opt problem, come to a solution with community power[tm]? -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
