On Wed, 19 Nov 2008 15:51:24 +1100 Brendan Simon <Brendan@BrendanSimon.com> wrote: > It seems to me that Emdebian is now being based on Squeeze (or later) > rather than Lenny (not even released). Lenny will contain the basic tools but Emdebian is not at all easy using the packages in Lenny. Changes are needed in a variety of packages to make Emdebian usable and those changes will not make it into Lenny due to the freeze (Emdebian issues are not release-critical for Debian Lenny). > Grip is targeted for Squeeze, and Crush is targeted for Squeeze or > later. Is my understanding correct ??? Almost. The current Emdebian packages are based on Lenny and work, a little. Improving these packages without substantial changes in the Lenny packages is hard. Grip (once development proceeds), could be able to work with Lenny packages - it could even work with Etch packages. However, replacements for programs like install-info and update-alternatives would be needed so that packages can be installed without looking for removed files. There are ways this could be done - custom packages spring to mind, using Replaces: etc. etc. To work with Emdebian TDebs, langupdate would need to be added as a customised package anyway. Current Emdebian (Emdebian 1.0) and what will become Emdebian Crush will need lots of support from changes within the development of Squeeze. Crush is targeted at Squeeze rather than waiting for Squeeze+1. > I would really like to develop based on Lenny debs. If need be, > could we have some fork (or "blend"?) of Lenny for Emdebian ??? You have those packages already - the Emdebian pre-built packages for ARM. The patches needed to create those packages mostly work but the known problems need wider fixes. If you can get them to work, fine. Extending those packages to armel and mips etc. is also hard - it is easier in some ways to do those customisations in a local repository. Once Lenny does release, I'll be doing the following: 1. Migrating the packages currently in Emdebian testing (http://buildd.emdebian.org/emdebian main testing) into Emdebian stable (tagging this as Emdebian 1.0 (based on Debian 5.0 "Lenny)). 2. Test the current tools against Lenny and arrange a backport of emdebian-tools, dpkg-cross and apt-cross (probably via the Emdebian repositories rather than backports.org). 3. Start the Code Audit to file the bugs that will implement the fixes that are holding back the current Emdebian packages. Emdebian 1.0 will be a stable base set of packages for development. (Think of it in terms of Slackware 1.0 or RedHat 1.0 - difficult to prepare, difficult to install, difficult to upgrade but can work with effort). The main objective is that Lenny can at least be a suitable platform for building Emdebian and (like Debian,) the target for such builds would be Sid, migrating into testing which will be Squeeze. Lenny can be used to build Emdebian (any flavour) but using packages *from* Lenny will lead to known (and significant) difficulties. It might work, but I'd expect it to be hard. My advice will be to use Lenny but use packages from Squeeze. > I just think that Squeeze is going to move way too fast to be able to > do reliable/stable development. That is why I want to release Emdebian 1.0 and ensure that Lenny is a *platform* for building Emdebian without necessarily being a *target* for Emdebian. I'll continue maintaining the cross-built packages and gripped packages and migrating those into testing as the tools are developed to make the whole management solution easier. (Quite what happens regarding the ARM and armel ports will be, umm, interesting.) Yes, development in Debian Sid will get a huge shot in the arm once Lenny is released because there are lots of changes awaiting upload into Sid, including the inevitable gcc-4.4, glibc improvements, dpkg changes and GNOME 2.24 and subsequent releases. However, testing will still be protected by the normal Debian processes and testing, of course, starts with Lenny. > Is there any support or use case for using Emdebian Lenny ??? I'm not sure I can really support it - getting fixes into Lenny is just going to be so much work. I will maintain Emdebian 1.0 and keep it updated as Debian 5.0 "Lenny" gets updated. > Can we have something like Grip that does not use Tdebs ??? I'm > presuming Tdebs is the reason Grip is going to be based on Squeeze. I can understand that presumption but it isn't accurate. Emdebian already has working support for Emdebian TDebs in Lenny. http://packages.debian.org/sid/all/emdebian-tools/filelist TDebs support in Debian is different and will not be fully implemented until Squeeze+1 - only the infrastructure will exist in Squeeze itself and nothing at all in Lenny. Bugs in packages like dpkg, apt, devscripts, dak, britney, reprepro and a possible host of other (unknown) packages, will need to be fixed in Squeeze. This allows Debian to make a stable release (Squeeze) containing all the infrastructure support for Debian TDebs, before actually providing TDebs for the packages themselves. Emdebian TDeb support will continue to develop alongside Debian TDeb support, of course. Emdebian TDebs are more granular than Debian TDebs (i.e. we have more, smaller, packages). The benefits of Debian TDebs will make Emdebian TDebs easier to manage, maintain, update and generate but the principles will remain. The main bugs in Emdebian 1.0 are listed in #480710, #484277, #480515, #480518, #480521, #481764, #497533, #497551 and all the bugs listed here: http://www.emdebian.org/bugs.php There are probably a range of other bugs that I need to file and fix but many of those are dependent on the others. The main barrier is actually the repository maintenance that I outlined in a previous message. http://lists.debian.org/debian-embedded/2008/11/msg00043.html This is preventing me from adding more architectures to Emdebian 1.0 - I just don't think I can manage the inter-dependencies without extra support scripts. These scripts are going to be easier to develop from the test base of Emdebian Grip because of the ease of automation. The barriers to "something like Grip based on Lenny" are relatively simple to fix - you will need an empty install-info script that replaces the one from dpkg. You will need a replacement update-alternatives script that does *not* die if a manpage alternative does not exist. With those bugs fixed (and possibly a few more that I haven't encountered yet), you could use standard Debian tools like debootstrap, debian-installer and even Debian Live. You will also need the langupdate package currently in Emdebian SVN in order to manage the Emdebian TDebs, you'll need some form of pre-seeding for Debian Installer (to prefer ext2 over ext3 and XFCE over GNOME etc.) That will get you Emdebian Grip from Debian Lenny (and make things a lot easier for me). ;-) File bugs against the buildd.emdebian.org pseudo-package in the Debian BTS. The real fixes for these problems will be implemented in Debian after the Lenny release, progressing into testing in due course and therefore becoming part of Squeeze. Where problems occur within Grip, fixes will need to be made in Debian Sid, (so that the needed architectures can be built for us), repacked for Grip and migrated into Grip testing alongside the migration into Debian testing. Bugs in the emdebian-grip scripts themselves will follow the usual pattern of updates in emdebian-tools. Depending on how things go, I'll see if updated emdebian-tools packages can be made available for installation on Lenny too (via the Emdebian toolchain repository, http://buildd.emdebian.org/debian main lenny). -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpafo4LDZ1Y2.pgp
Description: PGP signature