[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Status of Emdebian Grip



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?

I think the toolchain is valuable in itself because for those of us who once 
had to build cross-compilers and for those others who probably find themselves 
doing so using a variety of weird scripts from the Internet now (although it's 
become a bit better over the years), easily installable tools are a major 
time-saver. I imagine that the Raspberry Pi community benefits from them quite 
a bit.

> 4: I've stopped needing to use Grip in any active manner. My work now
> concentrates on ARMv7 and later, where storage is simply not a concern.
> Most of the ARM devices I now use and care about support both 64Gb SD
> and SATA.

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. 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.

> 5: The only "maintained" suite in Grip is unstable - where the
> maintenance involves automated scripts which are principally aimed at
> the full Debian integration which is still delayed.
> 
> Riku commented, when Grip was first announced, that storage was not
> going to remain the principle problem for Emdebian systems and the
> availability and affordability of 64Gb SD cards means that this is now
> the reality.

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.

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.

> Emdebian Grip has no role in "resource limited" deployments other than
> reducing the storage requirements, so if the ARM boards currently in
> active usage have no practical storage limits, it is time to reconsider
> the work involved in maintaining Emdebian Grip. (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?

> 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?

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.

What I really do miss or really can't get into is the cross-building of 
packages because there are lots of recipes but I never seem to get any of them 
to work, although I realise that this is an ongoing challenge and maybe beyond 
Emdebian all by itself.

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.

Perhaps I've rambled off into another topic now, and I apologise for that, but 
I don't want you to think that people don't find this work useful. Stuff I've 
done with Emdebian, albeit modest, has been deployed on ARM devices of various 
vintages, too, and I think it saved a lot of time and provided convenience 
that you just don't get with stuff like OpenEmbedded and other likely 
deployment candidates.

Paul


Reply to: