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

[edgar . soldin]

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
>