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

Re: Emdebian based on Lenny

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

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

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

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.

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

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

Attachment: pgpafo4LDZ1Y2.pgp
Description: PGP signature

Reply to: