On Sun, Aug 31, 2014 at 08:12:37PM +0200, Jérémie Courrèges-Anglas wrote:
> Giovanni Bechis <giova...@paclan.it> writes:
>
> > On 08/28/14 00:57, Jason Tubnor wrote:
> >> On 27 August 2014 21:29, Jérémie Courrèges-Anglas <j...@wxcvbn.org> wrote:
> >>> Untested so far, one nit below.
>
> [...]
>
> >>> ... the files are added here anyway. The CHANGELOG says that it was
> >>> fixed in this release, so it probably makes sense to ship those files
> >>> now. Anyone with a dropbox account?
> >>>
> >>>
> >> Correct, it isn't right. It is either included or not included :-)
> >>
> >> I have just created a dropbox account specifically for testing, it isn't a
> >> feature that I use duplicity for. All my testing was done on amd64, macppc
> >> with par2 (with and without), AWS S3, file and sftp.
> >>
> >> Dropbox testing has failed. The py-dropbox API is needed it looks like,
> >> something else for me to look at if this feature is to be used. At this
> >> point, I think, leave the @comment intact for the dpbxbackend and I'll
> >> revisit its inclusion when I have sorted the dependencies.
> >>
> >> Thoughts?
> >>
> > "from dropbox import client, rest, session", maybe py-dropbox or something
> > like that should be ported ?
>
> While dropbox support might sound like a nice idea (thanks for your
> work, Jason), I'd prefer to keep the RUN_DEPENDS list short. Those deps
> are optional and I don't think it makes sense to ask users to install
> support for all backends supported by duplicity (the list is long).
>
> With this in mind, I suggest that archivers/par2cmdline isn't added to
> RDEPS either.
>
> About the LIB_DEPENDS change, the warning:
>
> LIB_DEPENDS devel/py-setuptools not needed for sysutils/duplicity ?
>
> is due to a quirk in python.port.mk (MODPY_SETUPTOOLS=Yes leads to
> LIB_DEPENDS containing setuptools). duplicity does ship a .so linked
> against libpython, thus it makes sense IMO to use MODPY_LIB_DEPENDS.
> See http://marc.info/?l=openbsd-ports&m=140950775609271&w=2 for more
> details.
>
> This said, 0.6.24 works fine here for my use case (which only involves
> sftp). If you agree about the above points, this leads to this diff, to
> be committed when the python.port.mk issue is solved:
>
ok for me, maybe a multi package that adds dropbox, and other dependencies ?
I do not care, I use only file and ssh backends but maybe it could be useful to
someone else.
Cheers
Giovanni
