Mark, [shell code snipped]
> This is obviously an ugly solution - it seems to give the versions of > whatever you have installed. How should build depends be handled > properly? It seems to me that doing this completely manually would > require knowledge of the changes between every version of each depend. To some extent, yes. I usually start with completely unversioned build dependencies on just the library -dev and helper packages, and if someone actually uses a version of a depended-on package that doesn't work, I add it later on (Although this sounds like Microsoft strategy: I cannot help but tell people to upgrade their setup. Versioned build dependencies are just a formalized way of doing so). > Is it just a case of editing the results of the above script and then > testing the packages to make sure it works. Is it then the case that > developers usually have fresh woody installs for each package, or at > least a woody install for packaging (I am currently running sid). You should develop your packages for sid, as in an ideal world, the testing scripts will move your package to testing after working versions of the depended-on packages are available and everyone using testing should have the necessary packages. Of course it is still nice if it runs under stable and/or frozen, but IMO this is not as important as maintainable code (which is why I think the explicit $DEB_BUILD_OPTIONS parsing in debian/rules is bull if you use debhelper -- just build with full depugging information and let dh_strip do the right thing). > > Speaking of build dependencies: There is no libgtkhtml2-dev, > This seems to be available in sid only. Then it's okay. :-) Simon -- GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
