Hi,
Sorry if I missed something obvious, but why not calling it directly
from the sources instead of duplicating it in /debian ?
All right, I will call the script script directly.
> I will reduce the set of supported architecures in the control file to:
> Architecture: i386 amd64 ia64 sparc
> I guess that a package does not have to support all arches, or am I wrong?
The policy says that restricting architecture support should only be
used when the program is not portable. I think that is not the case of
BALLview. There is at least one more architecture on which it would be
definitely useful: powerpc. For slow architectures on which it does not
make sense to do some structural biology, it is still the responsability
of their lead developpers to decide that a package should not build. So
if it only requires to fix the configure script to support all Debian
arches, I would say: go for it!
The problem is, that my application is based on roughly
500,000 lines of code,
that we developed in the last years. I can not guarantee
that it will work on
the other platforms, especially because we are dependent
on external libraries,
that may show unsuspected behaviour.
What is even worse: I have no computer available to test
our software for example
on a power pc architecture. What happens if my package
fails to build on such a machine
and I get a critical "Fails to build"error?
Also note that there are options which you can give to dpkg-buildpackage
so that it builds the sources without building the binaries. As your
package is very long to build, it can be very useful, for instance to
add support to the other arches
Thanks for the tip ;)
Andreas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
