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

Re: optional package in Build-Depends (how?)

Hi Paul,

Thanks for quick reply.

On Monday 27 February 2012 13:00:32 Paul Wise wrote:
> See section 7.1 of debian-policy for examples on how to do that (you
> probably want linux-any for the arch):
> http://www.debian.org/doc/debian-policy/ch-relationships.html

Indeed it probably could be written as 

    Build-Depends: libgpm-dev [linux-any]

But the obvious drawback would be the requirement to know all architectures
where this package is available.
In this case Build-Depends configuration will be ineffective against changes.
Maintainer will have to track if the package was ported to new architecture 
and maintaining such relationships may potentially turn into expanded list of 
Perhaps it will work beautifully for dependencies which will never be ported.

But let's discuss more general case: 
 what if optional dependency is not ported to target architecture yet,
 or if if is not available in backports?

There are might be situations where defining optional build dependencies 
without architecture wildcard may be more error-proof and easier to maintain.

Another case I'm thinking of is when upstream is using unit-testing framework 
like 'valgrind'. I like to have post-build tests enabled. But this 
functionality requires an optional dependency. I don't want to risk my package 
to FTBFS because I put dependency only needed for unit tests to Build-Depends 
and it is not available on all our platforms. In such case using architecture 
wildcard is just inappropriate because availability of such package (may) have 
nothing to do with architecture. 

Specifically regarding 'libgpm-dev', I've made a list of architectures where 
it is available (below). At the moment I have no idea what 's390x' is (linux 
or not) so I have doubts regarding architecture wildcars to use.
(OK, I admit I've checked with 'type-handling any linux-gnu' command but I'm 
still confused how to use architecture wildcards properly in this case)

All of this makes me think about the approach to use essential alternative to 
make sure build will never fail because of my lack of understanding which 
platform will have the required package.

What do you think?

avr32 				N
hppa					N
hurd-i386				N
kfreebsd-amd64		N
kfreebsd-i386			N
s390x 				N
alpha 				Y
amd64 				Y
armel 				Y
i386					Y
ia64					Y
m68k					Y
mips					Y
mipsel				Y
powerpc				Y
armhf 				Y
powerpcspe			Y
s390					Y
sh4					Y
sparc				Y
sparc64				Y


Reply to: