> Marius Vollmer wrote: > >To be fair, libraries do not _need_ to be shared, sharing them is an > >optimization. > > True, but this is very inefficient on small-memory devices. It makes a > huge difference to have, say, 3 applications sharing a library instead > of having 3 copies in memory instead.
And it's also rather a waste of the developers' time if someone has already gone to the effort of Debianising/getting it to work in general. > How to resolve this? Ideally, library K should now be taken over by > some maintainer (who could be one of the two mentioned, or someone > else), but this time built as a universal library with all features > enabled, useful for all developers. The good thing about a shared > repo here is that at least the issue comes to a head quickly. Do we > have procedures for handling this? Is this actually a problem? I've done this a fair few times, either had someone ask me if I'd recompile something with different configure options, or said the same to someone else. I don't see much point in building with all options until/unless they are needed as you increase the effort/build time/probably the installed size/etc. I've got to say I find this a real annoyance when "porting" Debian packages that include every possible combination of external libs in their requirements (recursively), when not many of them are probably necessary for what I want and it means I need to get even more support libs working (and when I'm thinking of FORTRAN apps here, that's often actually a real pita). Cheers, Simon _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
