On Mon, 6 Sep 2010 17:06:21 +0100 Wookey <wookey@wookware.org> wrote: > +++ Neil Williams [2010-09-06 16:01 +0100]: > > On Mon, 6 Sep 2010 16:20:55 +0400 > > Sergei Poselenov <sposelenov@emcraft.com> wrote: > > > > > Hello all, > > > > > > I have a question regarding the use of the emdebian-tools in the native > > > build environment. > > > > There's no point in using emdebian-tools natively. > > Why not? If you want to re-build debian packages with a set of > patches applied for customisations, then it seems to be a good tool. Better to get the sources from the repository and build with the patches in place. The infrastructure of emsource never did operate without supervision / hacking. I don't recommend it. Even updating those patches to current versions of the packages will be difficult. emdebian-tools is dead, the mechanism could never survive without constant maintenance, it rarely worked first time for any updated package, it consumed more time than it warranted and it went into bit rot the moment I stopped doing anything with it. That is why I removed the code from Debian. The mechanism for Emdebian now is to use the Debian package and then emgrip. We do not have a mechanism for changing package functionality - the experimental scripts didn't work out either. > > Alternatively, if you want the busybox based system without > > perl, you should use the existing packages from Crush as source > > packages for your own native builds so that you get the patches already > > applied. > > That's a good idea, but still doesn't cover the case where coreutils > is OK, but you want to apply a set of local patches which need rebuilds. > Or even busybox-based but with a different set of changes to the ones > we made in Crush. What we had never worked reliably enough for it to be transferable to that kind of model. If you want to apply a set of local patches, fork the Debian packaging and maintain it directly. > > > From my past experience with the cross-toolchains and cross-builds, I > > > remember how painful could be a build process (used Den Kegel > > > crosstool scripts to build a toolchain; libtool-based packages was the > > > real problem to build in cross). > > > > Compared to the pain of waiting for native builds.... > > People used powerpcs for their desktops not so long ago. People still > use them to run bigiron servers. A native build on that platform is > not at all crazy. I still have the powerpc laptop which I had in Edinburgh building the cross toolchains - I'm aware of their relative power. I was attempting to point out that native builds are the way forward as being less painful than cross. i.e. I missed a '?' at the end. > > emdebian-tools only worked for Lenny and only for a small number of > > packages - many of which only cross-build at the versions that were in > > Lenny. If you try a rebuild from the Emdebian Crush source packages, > > you will get the original Lenny versions, not the updated ones with > > security fixes etc. and you will be locked into those versions forever. > > Emdebian-tools is (or was last time I looked properly) a mechanism for > taking debian packages, applying patches from svn and rebuilding them. It was, originally, but it's not a method I'd want anyone else to suffer. It was a mechanism, that's true, but it was a mechanism which failed more often than it worked. Please forget emdebian-tools, it isn't a supportable mechanism, never really was. The fact that we don't have a replacement does not mean that the obsolete version can be used. It broke immediately Lenny was released and it is not fixable - principally because nobody has enough time. > The part that is specific to particular versions of packages is the > patch set in svn, not the tools themselves. Sadly, not quite true. The tools are tied to one particular svn repository and the patches in that repository are obsolete. The mechanism needs a lot of manual work to keep it working. That is why the mechanism was removed. > Yes, updating that patch set is a lot of work, but it's rather less > work if you are not fighting cross-build problems at the same time as > trying to apply a set of changes. Indeed. It is highly likely that only a few packages will need changes, hence native builds and therefore no need for emdebian-tools. emdebian-tools was for cross-building an entire package set. For selective changes to a handful of packages, use normal Debian packaging instead. It's less work. > > If you can live with coreutils and perl, just use Emdebian Grip. > > If you can do what you want this way, this is excellent advice. > > > Can you use coreutils and perl or must you have busybox? > > And exactly what sort of changes do you want to make to individual > packages? > > Answer those two crucial questions and you can work out what might be > the most sensible route. ... without the answers to those two questions, we can't realistically help you. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpvUAh4F6vpk.pgp
Description: PGP signature