On Wed, 26 Sep 2007 15:49:50 +0100 Wookey <wookey@wookware.org> wrote: > > Yes - if those changes are to files in debian/* then emdebian-tools > > will pick up those changes. If you mean patches to the upstream source, > > you should use whatever patch system is used by the package and > > implement a patch in debian/patches (or wherever else the package > > stores patches). > > This is an area we need to think about. Nearly every embedded > developer needs to modify a subset of packages, uusally in minor ways, > but sometimes extensively. For emdebian to be really useful it needs > to make this as easy as possible. My first reaction is to consider ways to have the same binary package in the repository for all users to have available for the next upgrade (which may well involve changes in areas unaffected by the embedded changes) and some way to modify the behaviour of that package - preferably upon installation so that the package doesn't have to do lots of configuration stuff every time it runs. dpkg filtering could be useful here - we could provide extra files within the package or as a second package created by our cross-build (possibly even including binary patches built from the same source) that only get installed if certain dpkg filters are active. The selection of filters would be controlled by a configuration step within the Emdebian installation process - i.e. device specific and usually permanent. Occasional changes could be made with later cross-builds of base packages like dpkg itself. Package changes could be done via a foo-emdebian package that is generated from the Emdebian build and containing whatever binaries/files are necessary to implement the necessary changes during the dpkg installation. One downside is possibly more time spent waiting for the device to run the upgrade. > I currently use a boardname-config package to hack a load of files > after a chroot is built That type of package could also be formalised and added to the list of packages necessary to build a rootfs for that device. Both methods require a consistent and reliable nomenclature for that unique board/device. It could be similar to how the kernel modules are packaged and, indeed, the kernel itself may well require lots of different flavours that could depend on packages like these. OE uses dozens of kernel-foo packages - all very small but providing a granularity that provides the flexibility that we need. > because otherwise I have to alter 15 different > packages install scripts in non-obvious ways. Maintainer scripts can be modified to omit or use certain subroutines upon certain detection results. The configuration files created by the installer could be used to trip these detection operations in the Emdebian maintainer scripts such that one modified script can cope with all the necessary changes by using conditional calls. Yes, it may well involve a lot of package-specific work and may make some maintainer scripts MUCH bigger than otherwise but if we keep these subroutines sufficiently "clean" so that there is no chance of them being activated within normal Debian, I think we can get these adopted upstream. > But this is a bit of a > hack. Debian is not currently built with this stuff in mind and I'm > sure it could be made less painful, without having to become expert in > every package... Some stuff will always have to be package specific - if we can arrange for specific configuration flags to be created during the initial installation of the Emdebian base packages, we could create a system that can be used by lots of packages. > Initscripts is a whole area that needs work, for example - the > standard Debian ones are very slow and do a load of irrelevant stuff. > There is work on this in mainline debian, but I think more is needed > for some sorts of embedded work. This is the downside - the changes activated by the filters would have to be carefully tested to ensure that the least amount of code is active as possible. With the scripts themselves getting more complex, debugging is not as easy as simply replacing the scripts entirely. It depends if we want to be still maintaining forked maintainer scripts in dozens of packages in 10 years time - as with dpkg-cross. It's easy to replace the scripts now but if there is a way to carry those changes upstream, it is less work overall. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpHej6HPrX6q.pgp
Description: PGP signature