Re: Bug#790933: ITP: drive - Google Drive tool
On Sun, Jul 05, 2015 at 01:16:02PM +0200, Christian Seiler wrote: > A good example for this is the open(1) command: way back when Linux was > still in its infancy, somebody decided it would be a good idea to have > a command to run something on a different virtual text console, and > they named it 'open'. This is the reason why you have 'xdg-open' for > opening files according to their mime type (and that command is not > that known, because of its name), because 'open' was already taken. On one hand, had xdg-open used "open" anyway, nothing of relevance would actually have broken, since nobody uses the original "open" anymore. But in 5-10 years time we might have the same situation again, when xdg-open is obsolete. On the other hand, "open" on Mac OS X does something useful today, because they've made the pragmatic choice to break with the poor choice of the past. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150706085441.ga10...@chew.redmars.org
Re: Bug#790933: ITP: drive - Google Drive tool
On Sun, Jul 05, 2015 at 01:16:02PM +0200, Christian Seiler wrote: > So _please_, please choose a different name for the binary in > Debian,[1] because accessing a cloud service (that might not be around > in 10 years, see e.g. Google News as for how such things can disappear > in a relatively short time) is something really, really specific and > really shouldn't take up a generic name that will haunt us for years to > come. "gdrive" is not too objectionable IMHO. I'd rather not see a package offering "drive" accepted to the archive. > Also, _please_ don't symlink it - because then you're also reserving > the name because people are going to use it. Yes symlinking does not address this problem. > [1] Suggestion: 'gdrive', if that's not already taken by something e.g. > GLib/Gtk+-based (I haven't checked). Oh snap :) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150706085814.gb10...@chew.redmars.org
Re: Bug#790933: ITP: drive - Google Drive tool
I think nobody mentioned it, but there is already "grive" https://packages.debian.org/jessie/grive . -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cadstwjjw5wmoa8zwoj1ekj8omdrg+d8v7mzdb+lgerng8pn...@mail.gmail.com
Re: Bug#790933: ITP: drive - Google Drive tool
On 07/06/2015 10:54 AM, Jonathan Dowland wrote: > On Sun, Jul 05, 2015 at 01:16:02PM +0200, Christian Seiler wrote: >> A good example for this is the open(1) command: way back when Linux was >> still in its infancy, somebody decided it would be a good idea to have >> a command to run something on a different virtual text console, and >> they named it 'open'. This is the reason why you have 'xdg-open' for >> opening files according to their mime type (and that command is not >> that known, because of its name), because 'open' was already taken. > > On one hand, had xdg-open used "open" anyway, nothing of relevance would > actually have broken, since nobody uses the original "open" anymore. But > in 5-10 years time we might have the same situation again, when xdg-open > is obsolete. Well, the implementation could possibly be obsolete in 5-10 years, but I think the generic idea of "this command will open it's argument with some application suitable for that file" is something that transcends the current implementation. So xdg-open potentially reserving the open command is something I'd be completely fine with (had open not previously been reserved by something else), because any other sensible use of that command would IMHO entail the same type of functionality, possibly with a completely different implementation. (And that would be something the alternatives mechanism was designed for, btw.) As for xdg-open grabbing it anyway, see: https://lists.debian.org/debian-devel/2014/04/msg00835.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732796 Christian signature.asc Description: OpenPGP digital signature
Re: Bug#790933: ITP: drive - Google Drive tool
On 07/06/2015 10:58 AM, Jonathan Dowland wrote: > On Sun, Jul 05, 2015 at 01:16:02PM +0200, Christian Seiler wrote: >> [1] Suggestion: 'gdrive', if that's not already taken by something e.g. >> GLib/Gtk+-based (I haven't checked). > > Oh snap :) I did an apt-file search gdrive and it didn't find any binaries with that name, so the current archive doesn't contain anything in that regard. There is a GLib class called 'GDrive' [1], but since that's C API, I don't see how that could affect this. However, a quick web search revealed software package who's upstream name is 'gdrive', also for accessing Google Drive: https://github.com/prasmussen/gdrive The binary it provides is also named just 'drive', but with completely different command line options. Both packages appear to be written in Go. The one that was proposed in this ITP seems to be more feature-complete, though, at least from looking at the README. Christian [1] https://developer.gnome.org/gio/stable/GDrive.html signature.asc Description: OpenPGP digital signature
Bug#791564: ITP: linpac -- A packet terminal program
Package: wnpp Severity: wishlist Owner: Colin Tuckley * Package name: linpac Version : 0.21 Upstream Author : David Ranch * URL : https://sourceforge.net/projects/linpac/ * License : GPL V2 Description : A packet terminal program Linpac was previously in Debian but was removed due to bugs and lack of upstream support. The project is now under new management and is being supported upstream. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150706094153.1.33962.reportbug@grenache
Re: Bug#790933: ITP: drive - Google Drive tool
On Mon, Jul 06, 2015 at 09:54:41AM +0100, Jonathan Dowland wrote: > On one hand, had xdg-open used "open" anyway, nothing of relevance would > actually have broken, since nobody uses the original "open" anymore. I do, about every time I reboot a machine in single mode. It gives you more than one console. If you fail to open a secondary console when you begin, you won't have it when you need it and by then you might be in the middle of a big dd or rsync. But then, the canonical name for that command is "openvt" and not much would break if the "open" symlink was removed. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150706111058.ga12...@angband.pl
Re: Bug#790933: ITP: drive - Google Drive tool
Clint Byrum 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: https://github.com/odeke-em/drive/commit/17c5bbebddafae3e319297ff5ae26b52d7b67078 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 readme): "not supported nor maintained by Google" How about prefixing it with the original author's id: rakyll-drive (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 signature.asc Description: PGP signature
Re: Bug#790399: ITP: structlog -- tructured Logging for Python
Hi! On Wed, 2015-07-01 at 02:58:41 +0100, Filippo Giunchedi wrote: > On Mon, Jun 29, 2015 at 01:56:55PM +0500, Andrey Rahmatullin wrote: > > On Mon, Jun 29, 2015 at 10:22:30AM +0200, Adrien CLERC wrote: > > > Le 29/06/2015 02:51, Filippo Giunchedi a écrit : > > > > * Package name: structlog > > > It seems to be a Python library (in the main site, I can read that it is > > > used as an imported module), it should be named python-structlog. > > Not necessarily (as we are talking about the source package name). >· > indeed, most python modules I've looked at so far don't have the python- > prefix in their name I've always considered this a bad practice that I'd really like, we as a project, stopped perpetuating. One of the most (if not the most) important resource a distribution has to curate and arbitrate over is namespaces of many kinds, source/binary package names, version strings, filesystem objects, exposed APIs, etc. Here's a relevant snippet from a reply I sent on the bash8 ITP #748383: ,--- Also just following upstream when it comes to naming be it for source or binary packages is not wise in many cases. Lots of upstreams create packages or language modules in language silos, where those names are implicitly namespaced by being part of that language community/portal for example. Having Http be a perl module is fine, the same for a python or ruby module, not so much when it comes to integrating it in a general purpose distribution. Why should the http source package name be the perl implementation? Even if that source provided modules for many languages, why should it take over the canonical protocol name for its source package? Also the source package name is really pretty visible in many places in the distribution. The current practice of many python modules to just use the upstream name as the source package name is a namespace grab, wrong and unfair to the rest of the distribution, some quick examples to illustrate: appdirs argvalidate audioread distlib I wish other language teams in Debian followed the perl lead here. `--- This also grabs the non-namespaced name for actual possible programs for example. I'll be filing a bug on the python-policy document to request that binary *and* source packages be namespaced. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150706183930.gc12...@gaara.hadrons.org
Re: Bug#790399: ITP: structlog -- tructured Logging for Python
On Mon, 06 Jul 2015, Guillem Jover wrote: > On Wed, 2015-07-01 at 02:58:41 +0100, Filippo Giunchedi wrote: > > On Mon, Jun 29, 2015 at 01:56:55PM +0500, Andrey Rahmatullin wrote: > > > Not necessarily (as we are talking about the source package name). > > > > indeed, most python modules I've looked at so far don't have the python- > > prefix in their name > > I've always considered this a bad practice that I'd really like, we as > a project, stopped perpetuating. Indeed. Furthermore, unless there's a strong reason for doing otherwise,[1] packages which produce a single binary package should have a source package with the same name as the binary package. [And ideally, if they produce more than one binary package, the source package should share the same prefix as at least some of the binary packages produced if they are not named identically to one of the binary packages produced.] We don't need more crazy cases where src:A produces bin:B and src:B produces bin:A. 1: For example, they're currently producing bin:foo8, and are eventually going to be producing bin:foo9, then calling the source src:foo seems reasonable. -- Don Armstrong http://www.donarmstrong.com I'm wrong to criticize the valor of your brave men. It's important to die for one's country when it means being the subject of a king who wears a ruffled collar or a pleated one. -- Cyrano de Bergerac -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150706185459.GC6137@geta
Bug#791608: ITP: minizinc -- Constraint modelling language and tool chain
Package: wnpp Severity: wishlist Owner: Kari Pahula * Package name: minizinc Version : 2.0.4 Upstream Author : Guido Tack * URL : http://www.minizinc.org/ * License : MPL-2.0, MS-PL Programming Lang: C++ Description : constraint modelling language and tool chain MiniZinc is a medium-level constraint modelling language. It is high-level enough to express most constraint problems easily, but low-level enough that it can be mapped onto existing solvers easily and consistently. It is a subset of the higher-level language Zinc. . MiniZinc is designed to interface easily to different backend solvers. It does this by transforming an input MiniZinc model and data file into a FlatZinc model. FlatZinc models consist of variable declaration and constraint definitions as well as a definition of the objective function if the problem is an optimization problem. The translation from MiniZinc to FlatZinc is specializable to individual backend solvers, so they can control what form constraints end up in. In particular, MiniZinc allows the specification of global constraints by decomposition. I already maintain Gecode, which includes a FlatZinc interpreter. I intend to package minizinc and minizinc-ide to provide more use for Gecode. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150706194031.11890.33240.report...@sammakko3.piperka.net
