The Software Infrastructure


dflemstr

It's a ball.
Joined
Jul 31, 2008
Messages
2,514
Location
Stockholm, Sweden
Website
Visit site
Hello everyone,
I once again thought about the software management on the Pandora, and have some basic questions (NOT about the PND system, please refrain from talking about it!).

All of these questions are related to various problems that I've seen in other open source projects, and I therefore want to (kind of) warn the Pandora devs so that they don't repeat the same problems, by asking these questions.

So, here we go:
  1. How will core updates happen? A new downloadable image every so often that needs to be flashed (by a PC etc), or just through normal IPKG updates?
  2. The modifications that have been done to Ångström by the Pandora team (menu selector, kernel, drivers etc), are they contained in packages, so that they can be uninstalled/reinstalled/upgraded easily, or are they just dumped in the default image outside of the packaging system?
  3. Is there a package that tells us which "version" of the OS a Pandora is running? On Fedora for example, there's a "fedora-release" package that depends on everything in the basic Fedora distribution, and that package contains a file ("/etc/blabla") that in turn contains basic version information for the system. Is there something like that on the Pandora, so that I can type "ipkg install pandora-release" and get all of the "official" Pandora packages easily, and so that I can open a file "/etc/pandora-version" and get some basic information about which version of the Pandora OS the device has?
  4. Is there any file in the "factory default" Pandora image that isn't a "member" of a package? Could someone make sure that all files are managed by packages, before the Pandora launches, so as to avoid problems? What I mean is that there shouldn't be some random "/etc/rc.d/menuselector" file that was just put there by the authors; that file needs to be a member of a "pandora-menuselector-service" package (or similarily-named) so as to make it upgradeable and integrity checkable.
  5. Will we have access to the full Ångström repository on the Pandora and will it be enabled by default?
  6. Will there be an IPKG community repository for us who want to deploy stuff via IPKG (because the PND format is limiting)? How will such a repository be administered?
  7. What about Debian ARM packages? Will there be a tool to install them, or something that converts DPKG-managed packages to IPKG-managed packages?

I guess that's it for now. I'll edit this post if I come up with something more.
 
I doubt we'll be that organized at first (ie: panic until firstbatch, then get stable ;), but I can't speak for everyone.

Many of those details are not yet ironed out; djw is working all his moments on wifi drivers and so on .. so things are pretty stable as is for the dist, but people are all just working in their spare time, so they're working on 'next desirable item', and those are out-ranking the little details. (People may think 'this thing is long overdo, so at least the software will be super perfect, but they should remember that its all volunteer work too.)

So anyway, yeah..

Devices will be flashed and tested before shipping
The distribution will be as a flashable unit, followed by ipog updates
ie: An ipkg package can be applied against the firmware to apply various alterations; it is assumed that people will follow the recommended patch series.. ie:
base unit, plus patch 1, patch 2, and then patch 3. (I would assume patch 3 will not include patch 1 and 2, but its possible we could do that, we've not discussed it much.)
Likewise after awhile, full flashable units (like service packs for Windows) to bring everyone to known solid states, should they not widsh to patch along.

If we go ahead with the super clever union mechanisms in ROM, then we have a couple options; ipkg to apply against the firmware, but unioned out to users homedir, so that patches can be undone just by rm'ing the overlay directory structure... or have the packages hit the real and true structure (outside of the union instead of within it.) Still to be decided.

As to packages.. the way the angstrom system works is that you supply recipies and patches and so on against the build definitions, and out pops a ready to use distribution (ie: you tell it what to build when, what patchjes to apply and so on.) So I imagine it will be ipkg updates against core system as noted above, for the whole base system. I suppose you could be asking.. "when patch 1 comes out what is it?" .. is it a single patch that hits 10 different files, or is 'patch 1' actually a group oif ipkgs that do individual things? And ar ethey 'small patches' (update firefox exe but not its other files) or full replacements every time (update firefox and all its files, as if it was not there) .. ie: how self contained is the whole package versus components of a patch?

All good questions; I'm not clear myself, but perhaps the others are, I don't recall.

(I must admit myself .. I worked really hard for a few months, but then real life destroyed me for the last few months so I'm not as on top of it as I want to be right now :(

jeff
 
It certainly can boot from SD, thats how we're devving them; ie: we set up the boot and filesystem and such right on SD and turn the unit on.. it is very cool and should make recovery very nice :) ie: Most of us set up bootstrap files on SD1 and then the actual distro on SD2 .. so we can boot different distros just by switching SD2 :)

jeff
 
'uname -an', the rest of those questions might be better answered looking at the angstrom linux distribution and the ipkg system. You can fetch the current version at the component level, what files belong to what, pretty much the same as with rpm, portage or apt.

Curious as to exactly what are these, 'various problems that I've seen in other open source projects', you've witnessed that any possible answers to any of those questions could possibly solve.
 
Sphinxter said:
Curious as to exactly what are these, 'various problems that I've seen in other open source projects', you've witnessed that any possible answers to any of those questions could possibly solve.
Well, in Fedora (10 I believe it was) there were conflicting packages in the base distribution, just because nobody had tested installing all of the packages at the same time. Sure, the Live CD worked, because it hadn't been created by installing all of the base RPMs, but instead had just been taken from Fedora Rawhide, had been given some patches, and then been squashed into an ISO.

Then, in Arch Linux, the Chakra Live CD, there were trash files laying around that actually were from packages, but those packages weren't marked as installed. So, when you then tried to install those packages whose files were already present, you got pages and pages full of "conflicting file" messages, and due to a pacman integrity issue and different package version, all of the files ont he system had to be removed before the package could be installed, resulting in temporary breakage of stuff.

There have also been a lot of problems with various spins of the Ubuntu distribution, where an user just throws in "/usr/lib/libglib.so" in a DEB "just to make sure that the end user has that file". The result of course being even more file conflicts.

Etc.
 
Last edited by a moderator:
Back
Top