On Tue, Apr 06, 2004 at 04:05:54PM +0100, Wookey wrote: > 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.
I would still rather maintain a relative patchset to rules/control/etc than have an entirely separate dir. iHowever, I'm pretty new here, and I don't know how large changes are typical. And if we can avoid changes entirely, or make them part of the official package, the less time wasted. > > 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. Agreed. Copying the docs doesn't probably take that much tim, so instead of fiddling with dh_install and rules to avoid docs getting into the deb, we could just create a dpkg-squeeze tool, that rips the /usr/share/doc out of the freshly built .deb. And any other unneeded space-consuming stuff (menu structures, .md5sums, whatever). -- Riku Voipio | riku.voipio at iki.fi | kirkkonummentie 33 | +358 44 5000343 --+-- 02140 Espoo | | dark> A bad analogy is like leaky screwdriver |
