Re: [Duplicity-talk] On replacing tar, why not dar ?

On Wed, Sep 9, 2015 at 10:31 AM, Zach Adams <address@hidden> wrote:

libdar has binary packages provided for Windows and Mac OS and it says
it has been tested on several other systems as well. I don't know what
platform dependencies duplicity has at the moment, but if duplicity
eventually becomes a wrapper around libdar then it seems reasonable
that it could become cross-platform.

Zach

On Wed, Sep 9, 2015 at 8:49 AM, <address@hidden> wrote:

> i totally agree with every point you make Aaron. it should be an optional component as long as it is unstable or developed within a completely new forked differently named project, so users will be able to enjoy a working duplicity.
>
> just a sidenote. someone mentioned that using libdar would make duplicity more cross-platform. my experience is that each platform dependent library makes it more difficult to maintain/distribute a software for different platforms.
>
> ..ede/duply.net
>
> On 09.09.2015 15:38, Aaron Whitehouse wrote:
>> I haven't personally used dar. It looks as though it has some very
>> interesting features, but mainly only one (quite active) developer. I
>> see that public key encryption is only available in the pre-release version:
>> http://sourceforge.net/p/dar/feature-requests/67/
>>
>> I'm always nervous when people talk about a complete rewrite,
>> particularly in a small project and particularly where it is something
>> critical like backups (and you may not find issues until you come to
>> restore the backup many years later). It also reminds me of:
>> http://onstartups.com/tabid/3339/bid/2596/Why-You-Should-Almost-Never-Rewrite-Your-Software.aspx
>> http://www.joelonsoftware.com/articles/fog0000000069.html
>> It tends to create a pretty bad user experience: all the developers want
>> to work on the new version; all the users are on the old version; and
>> you spend all your time telling users that their bug will be fixed in
>> the new version, but that they can't use that yet because it isn't finished.
>>
>> Is there any reason that we couldn't do things more incrementally? Say:
>> 1. add in dar to do exactly what we currently use tar for (and no more;
>> potentially activated by a commandline option?);
>> 2. switch the default to write dar files (but read either type);
>> 3. as developers have time, we could replace pieces of home-brew code to
>> use dar's features when duplicity is using dar files; and
>> 4. if maintenance of the tar-writing codepaths is considered too much of
>> a burden, turn off tar file output (though keep tar reading code).
>>
>> I would expect it would create a much better user experience, if nothing
>> else, and would mean that we could more gracefully deal with things like
>> the user having an old version of libdar that doesn't contain the
>> required feature (taking the above example, use our encryption code for
>> public key encryption until the user is both outputting to dar files
>> *and* has a version of libdar that supports public key encryption).
>>
>> Just my thoughts and happy to be proven wrong by somebody who knows more!
>>
>> Aaron
>>
>>
>> On 08/09/15 16:54, Kenneth Loafman wrote:
>>> Except for rsync processing, dar does a lot of what we need:
>>> compression, encryption, hard links, split files, etc., plus it's
>>> fast. The backend processing could be done after the .dar file
>>> creation, so it looks like rsync processing is the only addition to be
>>> made. Granted, handling the signature files would be a PITA, but that
>>> could be done by dar as well. We would only need two file types, dar
>>> and sig.
>>>
>>> This would do away with most of duplicity's guts and make libdar the
>>> central player in duplicity.
>>>
>>> This does not sound like a bad idea to me. Someone else weigh in please.
>>>
>>> ...Ken
>>>
>>>
>>> On Mon, Sep 7, 2015 at 10:00 AM, Kenneth Loafman <address@hidden
>>> <mailto:address@hidden>> wrote:
>>>
>>> Don't really need to reimplement, just make sure that the python
>>> bindings are sufficient to access libdar fully. I think that
>>> driving dar from duplicity would be nearly a rewrite since I see
>>> so much that dar does would replace much of duplicity's
>>> functionality. It might even be easier to start with libdar and
>>> add the librsync functionality to it, wrapping all that with
>>> multiple backends. Just a wild thought, but it would give us a
>>> solid basis on which to add.
>>>
>>> A new structure like dar would solve a lot of the problems we
>>> currently have, including split signature files, better manifest
>>> handling, etc.
>>>
>>> Just a thought, but sometimes a complete rewrite solves a lot of
>>> problems.
>>>
>>>
>>> On Wed, Sep 2, 2015 at 9:30 PM, Meta Schima <address@hidden
>>> <mailto:address@hidden>> wrote:
>>>
>>> People have made some python bindings to dar, but
>>> re-implementing dar in python is probably not feasible.
>>>
>>> > -----Original Message-----
>>> > From: address@hidden <mailto:address@hidden>
>>> > Sent: Mon, 31 Aug 2015 11:35:12 +0200
>>> > To: address@hidden <mailto:address@hidden>
>>> > Subject: Re: [Duplicity-talk] On replacing tar, why not dar ?
>>> >
>>> > On 31.08.2015 02 <tel:31.08.2015%2002>:50, Meta Schima wrote:
>>> >> Hello,
>>> >>
>>> >> In regards to:
>>> >>
>>> >> http://duplicity.nongnu.org/new_format.html
>>> >>
>>> >> Why not use the dar archive ? It was specifically
>>> designed to
>>> >> replace tar, and adds all the features that you want:
>>> >>
>>> >> https://en.wikipedia.org/wiki/Dar_%28disk_archiver%29
>>> >> http://dar.linux.free.fr/
>>> >>
>>> >> It has also been in development for 10 years so is mature.
>>> >>
>>> >> Just a suggestion.
>>> >>
>>> >
>>> > tar is available as plain python module. are you aware of a
>>> python dar
>>> > implementation?
>>> >
>>> > ..ede/duply.net <http://duply.net>
>>> >
>>> > _______________________________________________
>>> > Duplicity-talk mailing list
>>> > address@hidden <mailto:address@hidden>
>>> > https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>>
>>> ____________________________________________________________
>>> FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
>>> Check it out at http://www.inbox.com/earth
>>>
>>>
>>>
>>> _______________________________________________
>>> Duplicity-talk mailing list
>>> address@hidden <mailto:address@hidden>
>>> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Duplicity-talk mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>
>>
>>
>>
>> _______________________________________________
>> Duplicity-talk mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>
>
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk

_______________________________________________
Duplicity-talk mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/duplicity-talk

From:	Kenneth Loafman
Subject:	Re: [Duplicity-talk] On replacing tar, why not dar ?
Date:	Wed, 9 Sep 2015 12:25:37 -0500