On Mon, Feb 3, 2014 at 2:31 AM, Neil Williams <[email protected]> wrote: > 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. > > 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. > > 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.)
Even on the Sheevaplug NAND, which is limited to 512MB, I found emdebian too difficult, and resorted to dpkg-exclude= and dpkg-include= (along with ubifs zlib compression). I believe that dpkg-exclude=, along with efforts to reduce the number of packages in debian (such as mandating the use of build-id's for dbg symbols and then making dbg symbols automatic and in their own new type of repository) is the way forward, rather than emdebian grip. -- Shawn Landden +1 360 389 3001 (SMS preferred) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/cajusizvzfsyfjr4uo8zxmvdaab4x7npe9u1xtnguh3jdgdp...@mail.gmail.com
