Re: splitting a package's source
Nigel Jones wrote:
If there are other custom build tools, you may just want to consider a
rsyncrypto-dev package, otherwise you might just want to settle with
rsyncrypto-test (people may not understand what regtest is a reference
to, I actually thought for a moment it expanded to "registration
test".
Ok.
As for Build-Depend, I doubt that, why not make -test a completely
seperate package,
That's what I was talking about.
have a rsyncryptotest binary to run the test
commands, and have that Depend on "rsyncrypto", that means you are
giving X user the option to run the test suite, by doing this, it
means that users who don't care (many sadly don't) aren't forced to
test something they don't want to.
I was aiming for something else, really. I was aiming for having a "make
test" as part of the make process. This way, if rsyncrypto suddenly
failed to work on PPC platform, I would get notified without having to
hope that the porting group would get around to it. The thing is that
I'm trying to put that into the standard rsyncrypto build system.
I was thinking of having rsyncrypto-test recommend rsyncrypto. This will
also be useful for users who build their own versions of rsyncrypto
(i.e. - without a deb). So I would have:
rsyncrypto suggests rsyncrypto-test, as well as build-depends on it.
rsyncrypto-test which recommends rsyncrypto.
The build process for rsyncrypto-test would only package files, not
actually compile anything.
The build process for rsyncrypto would run make-test after make, so that
if something went wrong I (debian maintainer) will know about it, even
if it's not for my platform.
It also means that users can easily verify any prebuilt binaries
quickly and easily.
They can do that with this scheme. I guess the main question is "should
debian/rules run make test, if upstream provided one"?
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html
Reply to: