On Mon, 3 Feb 2014 19:53:57 +0100 Paul Boddie <paul@boddie.org.uk> wrote: > On Monday 3. February 2014 11.31.42 Neil Williams wrote: > > There are point releases of stable and oldstable coming up soon and > > I am reconsidering the status of Emdebian Grip. > > > 3: I'm seeing almost no discussion on this list or on IRC about > > Grip - now this could be "no news is good news" but I *know* there > > are dependency problems in unstable and testing from time to time > > (the daily processing sends me a lot of email) but nobody mentions > > it. There are a lot of complaints about the toolchain situation but > > as I have reduced amounts of time for Grip, my toolchain time is > > nigh on zero. > > The way I see it (and forgive me if I've got this wrong again because > I spend time only occasionally doing embedded stuff before having to > do other things for most of the rest of my time) is that the > cross-compilation toolchain and the distribution are two rather > separate things, are they not? Entirely separate. > I've used Grip on the Ben NanoNote which has 32MB RAM and 2GB NAND or > whatever microSD capacity you can put in the MMC slot. So there is no need for Emdebian Grip on that device - the microSD is easily capable of having a standard Debian install. > People did put > Debian on the Ben before, but Grip is the thing I associate with > multistrap - I remain uncertain about whether multistrap is sensibly > usable with "normal" Debian - and so Grip seemed a much better choice > as a result. multistrap works equally with Debian and Emdebian Grip. multistrap is about creating a root filesystem from multiple apt repositories - it doesn't particularly care what is in those repositories as long as apt can use them. > I must admit that I've found myself wanting the man pages when using > Grip on the Ben, and there may well be no useful saving to be had by > dropping such things. If various other programs seem slow or large it > is quite possible that these are already slow and large and need > fundamental changes to work on such small platforms. Install Debian if you want manpages - you have enough room with microSD support. > I imagine that "Debian for routers" was what you had in mind for > Crush. And so it might be a bit much to expect Grip to fill that gap. Forget Crush, there is no work going into Crush. Grip was never going to be able to fit onto routers. That was the role of Crush but it is not a useful effort any longer. > > (Other architectures were added to Grip simply because we could, > > there never was any particular use case for architectures other > > than armel. Most armhf devices had already moved away from storage > > constraints. Reducing the number of architectures in Grip would not > > reduce the complexity of the update process at all.) > > Is it just a case of doing the same kind of work for each > architecture? The calculations take the time, not the processing of each package. A small amount of time is saved per architecture but a lot more time is spent calculating which packages are to be processed. Also, a lot of the calculation time is *manual* - some is scripted but there is always a need to fix up corner cases in testing by working out which package is broken myself, albeit with help from the edos tools. > > If you have interest in retaining Grip *and are prepared to provide > > some solutions to the issues above* then say so here. Otherwise, > > neither testing not point releases will get updates and we then > > ought to consider if unstable is worth retaining. > > At some point in the past, I think I got confused and thought that > Emdebian was all about cross-compiling the archive, but I suppose > it's just repackaging natively-built packages, or at least it is with > Grip. Thus, when I deploy mipsel packages on the Ben NanoNote, > there's probably some potentially ancient MIPS-based hardware > building those packages to start with, not an x86-64 server doing > cross-building. Or have I got this wrong again? Emdebian Grip processes packages which have already been natively built by Debian. So the compiled files will have been compiled natively. I'm not getting into whether the Debian mips/mipsel buildd's are "ancient" here but it is those machines which compile the mips/mipsel binaries in Emdebian Grip. > The things I think are really good about Emdebian are the deployment > tools and the toolchain. If the deployment tools - multistrap, mostly > - could work with normal archives, then I'm not sure I'd miss the > "Gripped" packages. I would miss the apparently more lightweight > on-device configuration that you seem to get with Grip, though. multistrap does work with Debian archives. Emdebian Grip does not give you lightweight on-device configuration - you can do the same by omitting Recommends from your package selection, which multistrap does for you. If you are only using a single repository (Debian unstable or Debian testing), then you can just as easily use debootstrap as use multistrap. If you have multistrap config for a single suite in Emdebian Grip, it's a one line change to point at a Debian mirror instead of an Emdebian one. > The only potential solution *I* might be able to provide is to help > focus documentation, partly to clear up misunderstandings like my > own, and partly to be able to lead people to a degree of success with > stuff like cross-building. Right now, there are probably three or > four sites trying to provide information about such matters, and I'm > not sure that the resulting combined information is very coherent. Please edit the wiki where it would help. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: PGP signature