Re: circular dependencies in debian -> impact on emdebian
On Sun, 2004-04-04 at 19:07, Riku Voipio wrote:
> 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.
>
My original suggestion was to generate a minimal document of the right
format saying "docs not built" for each tool, in case the output of one
tool is fed into another which might object to an empty or missing file.
> > Another thought was to add a --nodocs option to ./configure. However this would take
> > years to settle into all the software. (It is easier to implement however, but you have to
> > convince quite a lot of developpers )
>
> I'm not sure what was the discussion behind this, but it wont stop me
> from commenting. 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.
>
> In the cleanest case, the documentation should generated in binary-indep
> part of rules, and the documentation tools are listed Build-Depends-Indep.
> Thus you could just "dpkg-buildpackage -B" and the documentation build
> depencies won't matter.
>
> I think it might be worth to push a policy requirement that important
> packages should generate docs in binary-indep. However, like you said,
> policy changes take a lot time to materialize in packages.
>
That would be very nice.
> > 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.
> 2) Generating docs would still be relatively timeconsuming. When
> rebuilding the same packages constantly, you want to cut every
> minute from the build process.
The thing in its favout is that you can use the scratchbox control
mechanism to switch programs from host to native very easily, so it
could work out being quite simple. This sorts out library dependencies,
and could end up working very well.
Justin
Reply to: