On Tue, 10 Apr 2007 19:30:33 +0200 (CEST) jean-christophe.haessig@dianosis.org wrote: Keeping this on the list. > Yes, upstream must provide --enable and --disable switches, but many > projects already provide such switches, but the default behavior for a > (non-embedded) package mainainer is to enable everything. True but I'm not sure how much you can achieve by that alone. You still need to remove a lot of other stuff from packages. Take a look at emdebian-tools for some idea of what is being done for this. > > Insufficient - you will need to calculate the dependencies of the > > dependencies. e.g. libqof1 does not depend on libxml2, except that > > it uses libgda2-3 which brings in libxml2 for itself. Therefore, > > when building libqof1 for embedded use, specify --enable-embedded > > or remove libgda2-3 from the dependencies and libxml2 drops out > > too. This has to > > This is my point. Build the binary with the most restrictive options, > then build it many times, enabling each option. You still have to build the entire chain, not just that package - and then build the entire chain in each permutation. What's the factorial of 19,000? ;-) > > On an embedded platform, you won't be able to do any rebuilding - > > you need to cross-build and give the user binaries that run without > > patching. > > The builds (building from source) are done where the package is > created, not on the target system. So you are cross-building? This is exactly what emdebian-tools is doing. You cannot use --enable-foo options WITHOUT recompiling. It simply won't work. If you are recompiling on a buildd to install on an embedded device, you are cross-compiling (unless you have a lot of ARM machines around somewhere). Debian currently does not accept cross-building on the buildds and you would have difficulty persuading Debian maintainers to disable all the options that we would need to be turned off. If you want these dependency changes within the main Debian archive, you'll end up with MORE dependencies, not less. Desktop users will want the same functionality so you could end up turning 19,000 packages into 30,000 without adding new functionality. Even the smallest package could end up with dozens of dependencies and when so many are recommended or optional, aren't you going to need to patch apt so that recommended is installed by default on desktop machines? How does that help? Whether you create a source or binary patch, the ELF executable still has to be cross-compiled. dpkg-cross works on ARM executables built natively in Debian - it concentrates on libraries but can be used on applications. If that was all we needed, Emdebian would have used it. The problem is that dpkg-cross doesn't reduce the size of the package. If you are cross-compiling to use --disable-foo, you may as well make the final cross-built binary package available to the embedded user directly via the familiar tool: apt-get. > You may have missed my point : no recompilation will be needed. Recompilation will absolutely be needed to implement --disable-foo. > In > fact, my scheme targets the regular Debian, however, if it can be > done, the original Debian packages could directly be used for > embedded targets. Emdebian packages ARE Debian packages, just smaller and using a suffix to the version string to allow these to be built on the same system as "normal" Debian packages. > What I thought about is to create a minimal version of the binary, > usable, for example, in an embedded environment. Then, *binary* > patches to the executable will contain the stuff to add support for > additional libraries. Binary patches??? Why not simply provide the patched binaries as updates? I don't see the benefit of binary patches when apt-get is so familiar, easy and has an entire infrastructure available without cost or changes. To me, binary patches smack of proprietary software behaviour and have no merit over providing the user with the complete emdebian binary. Are you expecting users to update their embedded devices by low bandwidth connections? What are the advantages of binary patches? Binary patches are going to hard to debug - what happens when upstream makes a new release? A source patch can be applied to the new upstream, the package rebuilt and a binary made available (in many cases) entirely automatically. A binary patch would have to be regenerated from scratch every time a new Debian upload is accepted. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpf7QvmExMLV.pgp
Description: PGP signature