On Thu, 25 Oct 2007 16:11:09 -0400 Clint Adams <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 25, 2007 at 12:43:56PM +0100, Neil Williams wrote: > > It would be very useful for Emdebian if tzdata could be split into > > separate packages for each $TIMEZONE value in debian/rules. Users could > > then install just the packages needed for their embedded device without > > wasting precious flash space. > > If this is a good idea, I think we'd be better off combining some of > the unimportant ones (like solar87, solar88, solar89) into > tzdata-useless. Agreed. I suggested timezone granularity because that level is already implemented in debian/rules for parts of the build and because any automation sufficient to do the job could probably be extended by Emdebian to split the package even further. Single file packages would be ideal but see later. > Alternately, what about something along the lines of the locales > packages: one package with source (that compiles timezones "on-demand), > and another with everything precompiled. I'd rather not from the Emdebian side. This touches on another issue that needs to be considered elsewhere but Emdebian would like as much granularity as possible - even if that support is specific to Emdebian rather than implemented across Debian. Currently, Emdebian splits out all translation files (LC_MESSAGES/foo.mo) into generated packages for each locale and it would be good to tie that in with gconv in glibc and zoneinfo in tzdata but as Emdebian already has a 10 fold increase in the number of binary packages compared to source, this is clearly unsustainable. Something does need to be sorted out along the lines of a second archive that is not part of the apt-cache or dpkg data but which is uploaded, maintained and installed using a process specific to l10n and i18n - using apt but not cluttering the apt cache, maybe a parallel cache. That would allow translators to upload updated translations directly instead of waiting for maintainers. (And as an extra gotcha, such a system would have to be in C/C++ because the very devices that need this support won't be running perl, let alone python etc. Emdebian has recently solved the problems of removing perl from Essential - principally by ignoring Essential itself. :-) I do have some code that could do the job but until the job itself is more fully defined....) It is largely irrelevant to Emdebian whether the locales are pre-compiled or generated - the limiting factor is storage space. Hard disc space is cheap, flash is v.expensive - in cost as well as time. When the device only has 64Mb flash, most users would rather have a few more apps and room for more data than 30Mb of unused l10n support from a combination of glibc, tzdata and unused translations. Naturally, generation on the device isn't good but that would probably just mean I'd have to create a process to either pre-compile during the cross-build or simply ignore the packages that need generation on the device. > I see benefits and ugliness in both options, and the potential to make > the debconf questions even more complicated. No need to bother debconf. Debian can have a meta-package that depends on the widest range of support, as is typical for a Debian package. Emdebian can dump that meta package and offer a custom tool in userspace that configures the whole l10n/i18n issue in one operation by individually installing and updating packages that are specific to the needs of that one device. Just some ideas. I hope to raise these issues on debian-devel in a few weeks time but right now, I've got lots of packages to update... -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpySpqVPK2nD.pgp
Description: PGP signature
