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

Re: Bug#790933: ITP: drive - Google Drive tool

Clint Byrum <spamaps@debian.org> writes:

> Excerpts from Joachim Breitner's message of 2015-07-04 13:45:40 -0700:
>> Hi,
>> Am Samstag, den 04.07.2015, 17:16 +0200 schrieb Sophie Brun:
>> > Le 03/07/2015 21:46, Guillem Jover a écrit :
>> > > drive is an extremely generic name in tech, please use something 
>> > > else
>> > > when packaging this, both for the source/binary packages and the
>> > > executables and other related files. Prefixing it with «google-» 
>> > > could
>> > > be an option, perhaps. Doing this upstream would be preferable.
>> > 
>> > I followed your suggestion and opened this issue: 
>> > https://github.com/odeke-em/drive/issues/271
>> > But upstream doesn't seem to be agreed. What do you suggest?
>> you are free to choose your source and binary package name independent
>> from upstream’s choice. For example, all Haskell packages are named
>> haskell-foo, where upstream calls it just foo. So let upstream do what
>> he likes and do what you think is best within Debian with the Debian
>> package.
> Indeed. However, they've selected 'drive' as their binary command name..
> so following upstream's rather unfortunate namespace grab might actually
> be the right way to go, to make sure it's clear 'this is the package
> that owns drive in the execution path'.

It seems that this was not the first choice of name:


It was initially called 'god' by the looks of it, so I suppose 'drive'
is an improvement of sorts.  :-/

However, unless one is a user of google drive already, 'drive' seems
much more likely to conjure up the idea that it's something to do with
car navigation.  Even calling it google-drive doesn't help with that,
given the Google Maps angle.  Also, it would probably be asking for
trouble regarding trademarks given that this software is (to quote the

   "not supported nor maintained by Google"

How about prefixing it with the original author's id:


(or perhaps 'odekeem-drive' if the new upstream feels that their fork is
sufficiently distinct)

At least that is an even-handed approach that would deal with the other
implementations of the same idea that have also settled on the 'drive'
name for their binary.

Cheers, Phil.
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

Attachment: signature.asc
Description: PGP signature

Reply to: