On Tue, 2008-10-28 at 23:26 +0800, GNUbie wrote: > > OK, from your original message, it sounded as if you wanted Emdebian on > > a machine already running Debian Etch. How much flash storage space are > > you going to give the new system? What is your target installation size? > > Maybe up to 512MB of flash storage space. OK, that might be a little bit tight for a GUI based on Lenny, even with XFCE. However, I read below that you don't need a GUI so 512Mb is plenty of space. I'm still not sure what you want the device to do though because amd64 is a powerful architecture and I can't imagine that you'd get it to run without a fan or have much of a battery life if the device is meant to be portable, which makes it hard to see the appeal of solid state storage. > I am not entirely planning to target a real embedded appliance. I just > want to have a stripped down Debian (hopefully Etch because it's the > stable branch) especially without the docs, etc. and a read-only > filesystem. The target machine that I am planning is a standard AMD64 > box, either a clone PC or a branded one. So why the solid state storage? > Yes, I found the emdebian-tools at the Unstable branch but I also > found one at the EmDebian site. I am confused which one to use and > what is really the right way to do what I want to accomplish. You'll have noticed that the one via the Emdebian repository is a later version. emdebian-tools in Debian unstable is frozen pending the Lenny release but development of emdebian-tools continues in the Emdebian repository. Installing emdebian-tools from Debian (testing or unstable) adds the Emdebian repository to your apt sources so that you can have a cross-building toolchain installed and maintained. Alongside the toolchain, the repository provides updated versions of emdebian-tools and other support packages. So the normal / right way is to install emdebian-tools from Debian as normal, then get the latest versions at the next apt-get update; apt-get dist-upgrade cycle. This pattern will continue after Lenny because it allows us to always have the latest version of emdebian-tools in the Emdebian repository even whilst supporting delayed uploads to Debian to allow time for migration into testing. There have been many instances where I've made a new release of emdebian-tools within the 10 day period needed to allow the previous release to migrate into testing. That rate is slowing down now but it is still a useful option to keep the Emdebian developers as close as possible to the current state of Emdebian SVN. > > I think you are doing a similar kind of task to the Debian Eee PC port > > (which includes the Acer Aspire1) in that you want Debian with xfce and > > a few custom tweaks to fit the system into 2Gb or so. You don't need > > Emdebian to do that. > > I don't have any idea about the Debian EeePC port. As much as > possible, I just want to have a normal/standard Debian Etch AMD64 > install on my target system minus the docs, etc. and make it a > read-only filesystem. It's not really an embedded appliance. OK - the Eee PC port is more a set of tweaks rather than a complete new architecture. Once tweaked, Debian Lenny does run nicely on the Eee PC and the similar Acer Aspire1. > > If you do not want a graphic interface on the new system, you can do > > without X and xfce etc. so you could still use Debian. Depending on > > which packages you need, you would need anything from 300Mb to 1Gb for > > this. > > I don't need X at all. In which case, standard Debian will fit nicely. > > If you want a graphic interface but still want an installed size about > > 800Mb to 1Gb, you will be looking at Emdebian Grip which is in > > consideration at this time and has a little bit of scripting support but > > no testing. (No figures exist for just how small Emdebian Grip will be.) > > Any URL for Grip? I want to read their documentations. http://www.emdebian.org/emdebian/flavours.html emdebian-tools will provide a new package in v1.4.11 that provides a possible script to implement Emdebian Grip. The package itself (emdebian-grip), once released, will be independent of the other emdebian-tools packages. It's a bit awkward at the moment though - as Lenny is frozen, I can't upload emdebian-grip to Debian so even after I release 1.4.11 (probably later today), you'd need to get it from the Emdebian repository. emdebian-tools brings in quite a few dependencies that you don't need to run emdebian-grip so one way is to install emdebian-archive-keyring from Debian, add the Emdebian repository to your sources list manually and install emdebian-grip once I've completed testing and made the upload. emdebian-grip is a proof-of-concept only at this stage. It's not really ready for full deployment so it will be installed in /usr/share/emdebian-tools/emgrip. Once things settle out and I've got a better idea of how emgrip will develop and completed the rest of the code, I'll look into a separate source package or migration into dpkg-dev as dpkg-grip. The main idea with emgrip is to automate the process and assist in making a repository of "gripped" packages so that the size of the dpkg and apt databases can also be squeezed. That is where the name comes from, the next Debian release after Lenny will be Squeeze and if you squeeze a bit harder you get Grip, squeeze harder still and you get Crush - the flavour of Emdebian that yields the maximum potential for reducing the installation size of Debian, down to 24Mb installed for the kind of system you wanted. The purpose of grip is to remove the obvious targets - like documentation - and provide a more flexible implementation of the translation support in Debian. As yet, only the initial stages are complete - in particular, the translation support has not been implemented. These changes need wider support within Debian: http://wiki.debian.org/i18n/TranslationDebsDebconfMeeting Hence there is no particular role for Grip in Lenny, only against Squeeze. You are welcome to try it out but you can also simply delete /usr/share/doc/ and /usr/share/man after installation. Emdebian Grip will retain the copyright files (compressed) for legal reasons of distribution but you should be careful removing stuff from /usr/share/locale/ in order not to disable your translation support. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part