[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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],
   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 

I understand it much better now.

Thank you.


Reply to: