duplicity-talk
[Top][All Lists]
Advanced

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

Re: [Duplicity-talk] support for something like --list-increments.


From: Rob Browning
Subject: Re: [Duplicity-talk] support for something like --list-increments.
Date: Tue, 14 Jan 2003 00:48:47 -0600
User-agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu)

Ben Escoto <address@hidden> writes:

> There is a test suite, see the testing/ dir in CVS or using the webcvs
> interface at:
>
> http://savannah.nongnu.org/cgi-bin/viewcvs/duplicity/duplicity/testing/

[...]

> ).  Right now including the tests and the sample data they use would
> make the tarball several times bigger, so they aren't included.

Hmm.  Well, is there any way we could generate the test data during
"make check", i.e. via dd and /dev/urandom or just copy some of the
source tree data or similar?  That might help reduce the size.

IMO, even if the tests can't be easily reduced in size, I'd still be
happy to see them included in the normal distribution if they're
meaningful.  I'd be tempted to argue that duplicity is the type of
tool where "make check" should be run after nearly *every* build,
especially normal end user builds.  A case could be made that for a
backup program the tests are even more important than the
documentation.

One of the personal reasons I'd feel much better if the tests were
included is that I'd like to be able to run them from debian/rules.
Normally, I'll only be able to build and upload duplicity from an i386
machine, but as soon as the source package hits the autobuilders,
it'll be built for powerpc, arm, alpha, ia64, m68k, etc., and I'd
rather have my newly packaged version tested on all those
architectures before it gets to any end-users.  Though if you still
don't like the idea of having the tests in the main package, I can
probably just grab the tests and add them to the Debian package's
source.

Of course I'd still also be favorably inclined toward something like a
runtime "duplicity --test" option.  Aside from allowing users to test
the tool just before a backup run, I could also run --test in the
duplicity post-install.  That wouldn't catch a case where a new python
install breaks an existing duplicity install, but it would help catch
any system anomolies at the time a new duplicity package is installed.

> Thank you very much.  That would be of great help to some large
> percentage of duplicity users (30%?  More once its only an apt-get
> away?).

NP.  Shortly after I upload it to the archive, it should be available
using apt-get from the unstable distribution.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4




reply via email to

[Prev in Thread] Current Thread [Next in Thread]