On Sat, Jun 04, 2005 at 12:18:47PM +0300, Shachar Shemesh wrote: > Hi all, > > I am both the maintainer and upstream for a package called "rsyncrypto". > It's an encryption program for files with a twist (rsync friendly). > > Putting on my upstream hat, I am trying to make sure the package keeps > on consistently conforming to previous versions. To that end I have > created a regression testing infrastructure. It's a bunch of files > pre-encrypted and with their keys. It also has a script that checks that > the current version can still decrypt the original files in the > regression test suite. > > Here's the problem, though. These tests are binary files, that make CVS > sluggish and unresponsive. I simply cannot keep them on the same CVS > tree as the sources for rsyncrypto. As such, I want to split the > regression tests to a separate source file. > > Removing my upstream hat, and putting on my maintainer hat, I would > still like that building rsyncrypto will be able to "make test" and run > the regression test suite on the files. In effect, I need rsyncrypto to > be built from two source files. My question is, "is this possible"? > > One way I thought of doing it is to create a Debian package called > "rsyncrypto-regtest", and have rsyncrypto build-depend on it. That is > probably the best way to solve my specific problem, and will be what > I'll do, but I'm wondering whether there isn't another way of doing it. > Is it possible to have two source files build the same package?
You talk separate source *file*, I'm sure you mean separate source .tar.gz? If not, I don't understand you, as a source package consists of lots of files in a .tar.gz. I consider an extra package for this quite unneeded bloat. Putting on your upstream hat, I see no reason to not provide one tarball which includes those binaries next to the source files, and using some script to make your release tarballs that will convert for example base64-encoded binary files from CVS into real binaries at tarball-build-time. Fwiw, I never noticed CVS really being sluggish with binary files, but if so, you might want to resolve that in some way (by moving to a different version control system?). Or just do it mostly the way you do now, just create the release tarballs from the two sources together. It's good to have regression tests at build time, and they certainly should be enabled when available at build time (and the build fails if the regression test fails). Working around version control difficulties by making another Debian package is not really a nice way to do it, and for what it's worth, if that's indeed the only reason you have a second binary package, chances are high your package would get rejected for that reason when you upload it to the archive. I hope this helps, good luck! --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
