Re: emdebian development model
+++ Martin Fuzzey [2009-04-26 18:57 +0200]:
> Hum, not being a DD there are are a few things I don't understand in detail.
> I think I understand the basic sid->testing->stable migration and that
> in Debian (unlike some other .deb based distros) the actual binary .deb
> uploaded by the developper is used for one architecture and the others
> are built by the buildds
>
> What I'm not sure about (sorry a bit OT for this list) is how Debian
> handles something like:
>
> 1 Jan: Upload of package X built with current sid toolchain (say gcc 4.3.2)
> 1 Feb: Sid toolchain updated to gcc 4.4
>
> In this scenario what ensures that X is buildable with gcc 4.4? [until
> the next version of X is uploaded]. I use gcc as an example but it could
> apply to any Build-Depends.
The short answer is 'nothing'. The package was buildable at the time
it was uploaded, (and the buildds check all the arches other than the
one uploaded). But in fact it doesn't get checked against updated
dependencies until the next time it is built and uploaded. To deal
with this for important transitions such as new gcc versions, people
rebuild the whole archive with the new gcc and send bugs to
maintainers where packages fail to build (so they can be fixed before
the gcc becomes the default). For most build-deps this testing is not
done (and doesn't usually break things either).
This problemt will aflict emdebian too, but is actually a pretty minor
issue compared to our others, discussed in this thread.
> > 3. Cross-building for testing or stable is immensely more difficult
> > than cross-building for sid because all the dependencies change. Until
> > Lenny was released with (an old version of) emdebian-tools available,
> > it was all but impossible. Lenny has made that achievable.
> >
> I understand the second part of this (obviously until working tools are
> available it's hard to do anything) but not the first part.
Yes. I was going to pick Neil up on that too, but you (and he) have
covered it adequately. In summary cross-building is no harder in Lenny
then sid, but emdebian patches track sid so may be broken on Lenny. We
could have an svn branch supporting Lenny cross-patches. It'd need a
bit of through to work out exactly how it should work - keeping up
with sid is more than enough work.
But I agree that this is something people will want. I'll want it too,
wearing my 'work' hat, so working out a mechanism so that interested
people can look after it seems like a useful thing to do.
> Yes I am imagining one svn branch containing patches against the lenny
> version of the Debian packages to be used with the lenny version
> emdebian-tools [though if a backported version of emdebain-tools would
> be useful and possible why not] and another containing patches against
> the sid version of the Debian packages to be used with the sid version
> of emdebian tools.
Makes sense. Some way to try and encourage any work done in Lenny
branch to also make it into sid branch would be good.
> The time is
> approaching however when I will have to choose how to do the real
> userspace. I already know that the current set of crush packages is not
> sufficient for my needs (but I haven't evaluated the exact package set
> yet). I prefer the "emdebian vision" I outlined to the alternatives
> and don't mind if it entails a bit of extra work provided:
>
> a) I can realistically do that work in a reasonable time scale [for that
> I'll need to determine the exact packages I need and look at them]
> b) It's not wasted work that will have to be redone over and over again
> [the reason for my post]
> c) There aren't any show stopper technical problems [I need to look more
> closely at the space required for the package cache]
I hope we can work out a way to make this work for you. Emdebian needs
to be useable in the real world by sensible people like yourself,
otherwise it's just a (very interresting!) academic excercise.
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
Reply to: