Re: splitting a package's source
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
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Reply to: