duplicity-talk
[Top][All Lists]
Advanced

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

[Fwd: Re: [Duplicity-talk] Python GnuPGInterface integration]


From: Edgar Soldin
Subject: [Fwd: Re: [Duplicity-talk] Python GnuPGInterface integration]
Date: Fri, 27 Feb 2009 19:13:21 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080914 Thunderbird/2.0.0.17 Mnenhy/0.7.5.0

any news on this one? ... ede
--- Begin Message --- Subject: Re: [Duplicity-talk] Python GnuPGInterface integration Date: Mon, 16 Feb 2009 17:35:24 +0100 User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.5.0


A while back we had a bug report from one of the upstream distro
maintainers that GnuPGInterface had its own project and package and that
we should use that instead of our local copy.  He even included the
patches needed, so I implemented it.

the sourceforge page has one most recent version 0.3.2 from 2002 ... I can't see more recent packages and a library not changed in 6 years is either stable or not in use :) ... I get the maintainers point of view of redundancy and probability of shipping old libs with apps. But again GnuPGInterface seems stable and what we are using internally (it is not opening security holes to the outside) should be the choice of the app maintainers.

Also if it should be done this "distro maintainers" way it should be done _nicely_ with a detection routine in the setup and automatic download from sf.net servers or pointing out where to get it and disabling gpg support for the time being without it.

I'm thinking I should have refused
the bug report in the interests of all those that have to install
duplicity by hand.

Agreed. I think most people do so because of the lack of readymade packages for most distros.

Its almost impossible to get the version in a
previous distro updated, so a lot of folks rely on the .tar.gz files to
install the current version.

You mean duplicity or GnuPGInterface?
We distribute tarfile.py and pexpect.py now and both of those are
separate projects, as is librsync and GnuPGInterface.  I'm thinking that
to keep the upstream guys happy, I may just want to put a link to the
externals needed directly on the web site.

Just doublechecked .. on http://duplicity.nongnu.org/ under requirements all packages have links to their project homes. Off topic: It would make sense to mention for which backends ncftp and boto are needed for.

Maybe that would be sufficient?

Take for instance the standard use case on a fresh (crashed?) linux with standard components (python,gpg,librsync) and internet access: Assuming I don't have a recent duplicity in my distros repositories I would have to fetch GnuPGInterface and duplicity and have to do python setup.py install for both. Also assuming I have only shell access to some root server this would really bother me.

...ede

...Ken


------------------------------------------------------------------------

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



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

--- End Message ---

reply via email to

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