-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 10.03.2011 09:09, schrieb John Willis:
That is exactly how I plan to setup the .next stuff. At the moment the builds just point off to the Angstrom repos but the plan is to use the OpenPandora ones at the top and the main Angstrom ones 2nd. We can also choose to mirror all of Angstroms repo is we want.
Considering that the pandora firmware is likely to always be based on a snapshot of angstrom and angstrom might significantly differ in its packages (due to normal development) what is available in the current pandora firmware I think it would make sense to have a mirror of the angstrom repo (feeds, that is) based upon the versions of progs that are shipped on the pandora. So that eg stuff is liked against the same boost, jpeg, ... version.
Another benefit would be a possible increase of download speeds since the angstrom servers appear to be freaking slow (at least for me).
Angstrom already builds packages for the OpenPandora machine type (or compatible generic ARMv7) so we just need to push up the changes from .next into mainline (most important really is kernel and kernel config so it cascades down the build and is pretty close to what we ship in the firmware) that is really no big deal at all, once things are working well of course.
The only issue is making sure that we are actually staying close to current angstrom, which will require constant efforts that can't be guaranteed to happen "fast enough", so IMO the only way (when allowing to install extra packages using opkg at all and not just updates of the default packages!) would be to have our own mirror of angstrom packages compiled against the pandora libs.
None of this unfortunately gets us away from NAND abuse and people filling it up with packages, that was the initial problem that had us shy away from pushing OPKG and this model with the 1st release ;).
Personally I would not mind too much if there was no way to use opkg for *anything* besides updating the default firmware packages. Summing up the options that I see possible (while making sure that it is not too easy to break the system using an opkg update && opkg upgrade without modifying the opkg config files):
1) Create our own feeds for "all of angstrom" in a pandora specific way. This would require to create an additional feed or something like this mirroring all of angstrom and building it ourselves against the angstrom version on the pandora. Advantages of this: * Packages installed from the repo are very likely to not be broken due to wrong dyn linking. * You *can* actually use opkg without the fear that some important system libs will be replaced with versions breaking other progs. * Rather fast download speeds for the packages. Disadvantages of this: * Someone has to do the work to create the additional feed. * When creating the stuff the way that is used to generate the current firmware has to be checked to make sure that not too many (any) wrong things are added there. This should be a one time effort to make sure that the recipes are okay. * More bandwidth will be used on EDs servers. * It would be a mirror of the angstrom packages that would require someone to work on keeping stuff in sync and porting relevant security fixes over. This fragmentation of angstrom might be problematic, not sure. * Is is easy to swamp the nand with those packages, so some easy "cleanup solution" that is not flashing would be cool (some "automatically remove all opkg packages that don't belong to the default firmware" or the likes). * Is there enough CPU time available on the servers to compile *all* the stuff? There are some really huge packages part of the angstrom repos and building them will require some time...
2) Limit the pandora (in the default config) to only install packages from openpandora.org without mentioning the default angstrom package feed. Advantages: * It is less easy to destroy the system by upgrading some single packages using opkg to install something new. * Since there are currently only the firmware files available, swamping the nand is more difficult (okay, installing all -dev and -static packages *would* still fill the nand up...). * No additional work required to keep the stuff updated beside the work already done for the firmware. Disadvantages: * No huge repo of packages directly available (even if the packages might not work (at all)).
Personally I think that '1' would make most sense, if we find someone to get stuff set up to work and got enough resources (cpu time and bandwidth). What we should do anyway is add the "firmware feed" in the opkg config files as "main feed" (aka highest priority). Cheers, Nils Kneuper aka Ivanovic