Re: Build Dependencies (was Re: Sponsor wanted)
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 debian-mentors-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: