❦ 9 août 2017 19:57 GMT, "Dr. Bas Wijnen" <wij...@debian.org> :
> If the free options are limited to a point where it does not make sense to
> recommend them to our users, that means the non-free service should be
> recommended and IMO that means the program should be in contrib.
As a sidenote, I strongly think I should just shut up. This kind of
discussions always lead nowhere and people just forget them. But...
Let's take rclone.
Description: rsync for commercial cloud storage
Rclone is a program to sync files and directories between the local
file system and a variety of commercial cloud storage providers:
.
- Google Drive
- Amazon S3
- Openstack Swift / Rackspace cloud files / Memset Memstore
- Dropbox
- Google Cloud Storage
- Amazon Drive
- Microsoft One Drive
- Hubic
- Backblaze B2
- Yandex Disk
It says "commercial". Lot of commercial services. But, it would work
with free S3 implementations and it works with Openstack Swift which is
free. So, not in contrib, right?
Now, it is written in Go and it depends on a lot of libraries, notably those:
- golang-github-aws-aws-sdk-go
- golang-github-stacktic-dropbox
- golang-google-api
- golang-google-cloud
They should be in contrib. But then, rclone would be in contrib
(packages in main cannot depend on packages in contrib). So, our users
would just lose a software which can be used to migrate data from a
commercial service to a free service.
There are other examples and this can become insidious. Some highly used
libraries can depend on libraries only useful with a commercial
service. For example, golang-github-armon-go-metrics depends on
golang-github-datadog-datadog-go, a library only useful for the
commercial service Datadog. Pulling this library in contrib would push
to contrib all software from Hashicorp.
--
Use self-identifying input. Allow defaults. Echo both on output.
- The Elements of Programming Style (Kernighan & Plauger)
signature.asc
Description: PGP signature
