Re: circular dependencies in debian -> impact on emdebian
+++ Erik Andersen [04-04-07 00:02 -0600]:
> On Wed Apr 07, 2004 at 01:02:05AM +0200, Philippe De Swert wrote:
First I'd just like to say that I'm pleased to see this discussion of real
details taking place. We need to sort out how best to do this and the more
people who've looked at/thought about this stuff put their ideas in, the
better the sceme we are likely to come up with.
We have some conflicting goals and there is probably no perfect solution:
We want to keep in step with mainstream Debian - that means not breaking
existing packaging, making life easy for existing maintainers, and making
our differences easy to maintian.
We need to change build rules (or sometimes just build tools)
We need to change dependencies
If we split packages then we need to add rules files and possibly make quite
extensive changes.
There is also the need to cater for the variability of target systems. For
almost any given real-world system the producer is likely to want to change
Debian/emdebian in various, but remain in sync as much as possible (i.e.
just the same as the Debian/Emdebian relationship, but one step further down
the line). Thus it seems to me that if our mechanism allows for 2 stages of
customisation away from pure Debian that will be a much more useful and
powerful system.
It's possible that what we actually want to do is something like
OpenEmbedded which is a set of metadata for each package saying something
like 'start with this source (debs), apply these patches (emdebian,
vendor/producer), build like 'this'. And having a class system to say 'all
these packages are done the same way'.
Of course if you go this far then maybe we start to get away from the
advantages of using Debian, which already has a layer of meta-build
information over the original release, and what we are currently thinking
about is how best to add more/different meta-build info to the Debian scheme.
I agree that simply copying things so two copies exist (and one can get out
of date) is to be avoided as much as possible. This argues against a
parallel 'emdebian' directory.
On the other hand mixing in significant changes to the rules files could get
messy very quickly. The need to change more than just the rules
(control, sometimes other stuff), argues in favour of a parallel directory.
Maybe we should allow a set of debian/patches to applied - that avoids any
copying.
> > > > Would this strategy avoid the need for a modified copy of
> > > > the rules files ^^^^ in a separate emdebian directory ?
> >
> > The advantage is that we can add all our stuff in such a dir,
> > without annoying the regular Debian crowd.
>
> If debian-embedded is going to completely reinvent the wheel,
> they could just as easily reinvent the world using gentoo or gar
> or whatever. What you are proposing effectively means scrapping
> the entire existing debian packaging code base and starting over.
> I do not think the current packaging is sufficiently broken that
> it requires yet-another-entirely-new-and-different system. I
> think it would be much more sensible to work with the current
> debian build system and adjust things as needed....
No - we're trying to modify the existing system to allow one or two layers
of change. Sorting out the best/most suitable mechanism is still up for
grabs, although I of of the opinion that the best descisions will be reached
by actually trying things and proving them for a sample 'distro'. Philippe
and I are trying this now using an emdebian/ dir, but we're not wedded to
the idea if better schemes are suggested. It's just a practical test.
> > Anyway we also need changes to the control file. We need to use
> > another naming scheme, just to keep Debian and Emdebian
> > packages apart. Also the dependencies will be different for an
> > Emdebian or Debian package. (Will certainely happen if we start
> > splitting up libraries to gain space. Who needs libcrypt or
> > similar on his system if he has no application which uses it?)
>
> If every debian-embedded .deb package depends on uclibc, I think
> that should be sufficient to keep people from doing any sort of
> unwise mixing of binaries....
That does have the advantage of simplicity, but it's not a general solution,
should people want to use glibc for some reason.
Wookey
--
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
Reply to: