Re: circular dependencies in debian -> impact on emdebian
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.
> 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.
> 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.
--
Riku Voipio | riku.voipio@iki.fi |
kirkkonummentie 33 | +358 40 8476974 --+--
02140 Espoo | |
dark> A bad analogy is like leaky screwdriver |
Reply to: