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

Re: circular dependencies in debian -> impact on emdebian



+++ Riku Voipio [04-04-04 21:07 +0300]:
> On Sun, Apr 04, 2004 at 04:47:40PM +0200, Philippe De Swert wrote:
> > Erik proposed a scheme were we would install a fake-documenation-tools package which 
> > would satisfy all dependencies and send the documentation to /dev/null. As simple as it 
> > sounds to use as hard it seems to me to actually implement this. 
> 
> Actually, I don't think it would be hard at all to implement. Sidenote: we 
> can't just throw documentation to /dev/null, the rules file copying docs to 
> build directory might barf on missing files.  So fake-documenation-tools 
> should rather create 0 byte files, which might be considers a ugly hack.

If we accept that we need to create modified emdebian/rules files, rather
than sticking with the standard debian ones and changing the build environment,
then the problem of such barfs can be fixed in such modifications.

I think we have accepted that we aren't going to be able to just use the
standard /rules because there are too many things we want to change.

By the same token of course we could fix the build-dependencies (rather
ruthlessly) by simply removing all the docs packages. This may not work for
some packages which use doc packages to generate important files, and I
don't think this is the way to go. I was favouring simply not copying docs
into the final packages. It's true that this wastes some time.

> It's not as easy to add a new --configure option,
> since almost every package has it's unique way of creating and
> installing documentation. Few packages use upstream provided 
> "make docs", sometimes documentation building is part of "make install",
> or maybe docs are generated in debian/rules. Some packages create
> documentation into $package-doc.deb, while others ship the docs in
> the main package, etc.

All true. Quite a lot use debhelper to install the docs I think. Not sure
what percentage. I think nobbling debhelper is quite a cheap win in this area.

> > As I was thinking about it for a longer time, I started to look at the problem in another 
> > way. You only need to satisfy those dependencies on build time, right? So when 
> > cross-compiling if these tools are on the build system the build will run correctly. If you 
> > throw away the docs when building the binary package (which is quite easy) the problem  
> > is solved. (it doesn't even matter if the docs are correctly generated or not, we do not use 
> > them). As we have support for a different control, rules, etc file in the emdebian sub-dir (I 
> > implemented it, it works, but I'm not sure if it is completely functional. Bugs could still 
> > appear) this shouldn't be to hard (we have full control of the build specifics, which 
> > debhelper scripts we will use and of course the dependencies). 
> 
> It would be quite complicated to know what packages are needed in the
> target platform format (dynamic libraries, etc), and for which ones
> the host platform package is only necessary. It is usually simpler to have
> a chroot on the host system that has the same packages installed than
> the target system. Even if solved, some problems remain:
> 
> 1) The overhead of maintaining separate emdebian dir. Ofcourse,
>    maintaining changes to debian/ dir files will be necessary 
>    to some packages anyway.

This is a fundamental problem which we want to minimise, but as you observe
we have to do some maintenance whateer happens. This is minimised by pushing
all this sort of policy up into Debian as 'Debian policy to keep Emdebian
happy', which is possible in the long term. I'm not sure it matters much
exactly which files the changes live in - whatever makes a practical solution.

> 2) Generating docs would still be relatively timeconsuming. When
>    rebuilding the same packages constantly, you want to cut every
>    minute from the build process.

True. Combining the 'fake-build-tools' concept with the 'don't copy the
docs' idea would fix this. A medium-term aim, I think.

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: