View Single Post
Posts: 567 | Thanked: 2,965 times | Joined on Oct 2009
#22
Originally Posted by Wizzup_ View Post
Perhaps I am not understanding what you mean (and I agree with the rest mostly), but this seems inverted to me - why would you take new bits and nail them onto the old base?
What I mean is that the specific packages in point 1 (e.g. libc, kernel etc etc etc) will come from Debian/Devuan and we will either point to the built .debs directly (if there are suitable .debs out there compiled with the options we need) or we will point to the source for those packages and have our build system pull that and build it.

For example, right now we are getting our libc from glibc version 2.5.1-1eglibc27+0m5+cssu3. This provides libc.so.6. On Debian Sid (as an example), the version of glibc is 2.24-17. This also provides libc.so.6. And because of the way backwards compatibility is generally handled with shared libraries on Linux systems we can use the newer libc.so.6 and still allow programs linked against the older libc.so.6 to run as-is. And if glibc then gets updated to some newer version, we just pull that in and use that instead.

In regards to the WiFi stack, the number of things that said stack exposes to the outside world via dbus, glib or otherwise and that are used by things outside of the WiFi stack is minimal (figuring out just what is exposed is on my todo list). I suspect it will mostly be some gconf keys under /system/osso/connectivity/IAP that will need to be in place.

Once we know that, we can easily rip the whole WiFi stack out and replace it with wpa_supplicant and other things instead.

In regards to the root CA store, the easiest solution there is to write a shim library that looks just like the one in maemo-security-certman but talks to whatever new way Debian/Devuan/etc uses for the root CA stores underneath. Modern packages that already talk to the root CA store with the new way will continue to do so, older FOSS packages that we are keeping (if any) get ported to use the new way and those binary packages we are keeping per point #5 in my original post will use the shim library (e.g. we will need the shim library if we dont clone and replace location-proxy)

Being API/ABI compatible with Fremantle is probably not going to be as hard as everyone thinks it will be assuming we intend to keep the whole Hildon UI and things (and if we don't then what's this whole project about?). I suspect the appropriate current version of many libraries will be ABI compatible when build with the right compiler options (armel etc) without any work required by us. (of course if Nokia forked these libraries and specifically changed their API/ABI, then that is an issue but even there we could very well be able to get away with a shallow patch set on top of upstream and just port that patch set every time we move to a new upstream version)

Points #1 and #2 from my initial post probably mean we can replace a lot of the core Maemo system with things straight from upstream somewhere. (e.g we dont need microb for web browsing anymore we just need some sort of modern up-to-date maintained browser that can run on our hardware)

Oh and in regards to the comment about idiots and extras-devel/cssu-devel, even really smart people who have been around long enough to know better sometimes screw up and install broken packages (at least its fairly easy to fix things when something does go wrong assuming you have enough battery power to get RescueOS to run
 

The Following User Says Thank You to jonwil For This Useful Post: