On Thu, 24 Feb 2011, Nils Kneuper wrote:
# Codec pack: # - -------------------------- # Another thing that should be considered for the next firmware series is how to # act in regards to the codec pack with mplayer and such. JDGBOLT is currently # working on "panplayer" which should offer some good generic support for a lot of # stuff. The question together with this are: # 1) Does it make sense to offer a codec pack once a decent "complete bundle" for # the mplayer is available? # 2) If that is the case, are there easier ways than manually gathering a list of # packages and "brute force" installing them using opkg? Is there someone # available with the knowledge and time to do this?
A codec pack of some sort is still needed; some may just want mp3 support, not movies; and putting them all into every pnd is fine, but given their frequency of use, might be better to have packs to install them? (ie: a la timidity).
Until such time we sort out how to do pnd-dependancies well (if at all.)
Firmware repo: -------------------------------
Something else to consider here is .. we have a semi-working repo, so that pandoras can point to and do opkg update and suck down the most recent updates; are we going to try to formalize this, or rely on hotfixes?
I mention it due to -- codec pack; could have its own repo as well; folks could set to sync up to firmware repo, and to codec repo, and do automated updates to both.
# Backwards compatibility: # - -------------------------- # The new angstrom version will change several libs that are often linked against. # The most prominent examples are probably libjpeg.so.6 (will be libjpeg.so.8 # after the upgrade) and boost (they got the version number in the mainly used # name, too). The question now is: Do we accept it that a major update of the OS # potentially breaks many existing PNDs? Should we advise the developers to # package the libs linked against in the PND, just using them as backup (aka # appending the lib/ folder in the LD_PRELOAD var)? Or would it make sense to # create a package ourselves with the most common "old libs" while having the # symlinks point to the latest ones. This step would increase the size of the # firmware and I don't know by how much (and for which libs this would really make # sense, the major examples with compatibility probs that come to my mind are # boost and libjpeg).
Personally, as long as NAND has space, I'm a fan of bundling deprecated libs in; ie: as long as we can symlink safely (compatible binary interface) we're cool; when a symlink or auto-versioning will not do, we include newer and older versions.
It is never cool to break 500 applications when switching to a new OS version...
Ugly hack: pnd_run.sh could do an ldd against contained executables, and when known libs are now missing, it could notify user to pull down some pack of libs to make things work. Lame as hell though.
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.