Re: optional package in Build-Depends (how?)
Hi Craig,
Thak you for sharing your experience.
On Monday 27 February 2012 14:09:21 Craig Small wrote:
> That's the problem I have with mudlet.
> libluajit-5.1-dev [amd64 armel i386 kfreebsd-i386],
> liblua5.1-0-dev [!amd64 !armel !i386 !kfreebsd-i386],
>
Very interesting and useful.
This is exactly what I'm afraid of. How can fellow maintainer track the
changes in all architectures effectively? I imagine the maintenance pain for
such configuration and it is probably breaks once in a while...
> It's not pretty and basically means if other arches come along and
> support libluajit I have to manually fix it. I don't think I could use
> "or" | because it didn't work on some build systems.
I see...
> A "or nothing" would be handy but I always get worried that you will
> miss linking because of a transistional "bump" then the program
> behaviour changes.
>
> Imagine if on the armel libluajit is not available temporarily. I think
> its better to fail to build than to issue out a package without that
> linking.
This is a very valid point, thank you.
You're right, if libgpm-dev is not available on i386 or amd64 for whatever
reason, build should fail rather than ignore the problem.
Which makes this dependency package optional only on some architectures so I
probably need to use something like
libgpm-dev [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386],
or
libgpm-dev [linux-any],
It's not too bad after all.
> Specifically to your testing, valgrind testing should probably be
> opportunistic, so test if valgrind is available and don't otherwise. I
> think dejagnu does it that way.
OK, so for really optional packages like 'check' or 'bison' it may be
appropriate to use something like "check | dpkg" if we're not linking against
it.
I understand it much better now.
Thank you.
Cheers,
Dmitry
Reply to: