Le 03/11/2013 11:28, bastien ROUCARIES a écrit :
> Should we add a lintian test for this kind of problem ?
http://lintian.debian.org/tags/script-with-language-extension.html
signature.asc
Description: OpenPGP digital signature
> On 3 Nov 2013, at 15:28, Thomas Goirand wrote:
>
> The problem
> with /usr/bin/ collision is *only* when we have 2 software
> doing completely different things using the same /usr/bin/.
We've already established that the tools are not command line compatible.
--
To UNSUBSCRIBE, email to d
On 10/31/2013 10:21 PM, Yaroslav Halchenko wrote:
> there is a non-free original MNE which provides some of those
> tools implemented in C. Happen MNE gets freed (and packaged) or
> otherwise installed -- there would be a conflict (command line interface
> differs, alternatives is not the way).
H
On Saturday 02 November 2013 08:33:54 Paul Wise wrote:
> On Fri, Nov 1, 2013 at 11:09 PM, Yaroslav Halchenko wrote:
> > in any case -- upstream seems have liked a 'gateway script' solution:
> > https://github.com/mne-tools/mne-python/pull/866
Should we add a lintian test for this kind of problem ?
On Fri, Nov 1, 2013 at 11:09 PM, Yaroslav Halchenko wrote:
> in any case -- upstream seems have liked a 'gateway script' solution:
> https://github.com/mne-tools/mne-python/pull/866
Sounds like a better solution anyway, thanks.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE,
On Fri, 01 Nov 2013, Charles Plessy wrote:
> I recommend if possible to keep the original upstream name if it has a suffix.
> Not doing so means that Debian becomes incompatible with other systems and
> with
> the existing documentation.
> > So the question is -- is there any other possible resol
On Fri, 01 Nov 2013, Paul Wise wrote:
> > So the question is -- is there any other possible resolution I do not
> > see here besides just keeping .py suffixes and providing a lintian
> > override?
> The implementation language is irrelevant to users and thus should not
> be in the names of things
On Thu, Oct 31, 2013 at 10:21 PM, Yaroslav Halchenko wrote:
> So the question is -- is there any other possible resolution I do not
> see here besides just keeping .py suffixes and providing a lintian
> override?
The implementation language is irrelevant to users and thus should not
be in the nam
Le Thu, Oct 31, 2013 at 10:21:54AM -0400, Yaroslav Halchenko a écrit :
>
> So the easiest resolution is IMHO to maintain .py suffixes, but I feel
> unease about such a solution despite archive having a good number
> of precedents already.
Hi Yaroslav,
I recommend if possible to keep the origina
On Thu, Oct 31, 2013 at 04:36:35PM -0400, Yaroslav Halchenko wrote:
> the hurdle again is that those then would/could conflict with the names
> of the now non-free MNE toolkit, which ships files with the same names.
> This Python toolkit pretty much tries to mimic and interface in few
> spots the o
On Thu, 31 Oct 2013, Peter Palfrader wrote:
> > the hurdle again is that those then would/could conflict with the names
> > of the now non-free MNE toolkit, which ships files with the same names.
> Sounds like both packages should pick new names
well -- in their universe they have no problem to
On Thu, 31 Oct 2013, Yaroslav Halchenko wrote:
> the hurdle again is that those then would/could conflict with the names
> of the now non-free MNE toolkit, which ships files with the same names.
Sounds like both packages should pick new names and/or install into
their own directories and the "int
On Thu, 31 Oct 2013, Jonathan Dowland wrote:
> On Thu, Oct 31, 2013 at 03:24:02PM -0400, Yaroslav Halchenko wrote:
> > > Urgh. How about installing the .py to a private directory (under
> > > /usr/share say?) and creating non-suffixed symlinks in /usr/bin.
> > how that would help in case of a c
On Thu, Oct 31, 2013 at 03:24:02PM -0400, Yaroslav Halchenko wrote:
> > Urgh. How about installing the .py to a private directory (under
> > /usr/share say?) and creating non-suffixed symlinks in /usr/bin.
>
> how that would help in case of a conflict with original MNE's binaries
> becoming avail
On Thu, 31 Oct 2013, Jonathan Dowland wrote:
> Urgh. How about installing the .py to a private directory (under
> /usr/share say?) and creating non-suffixed symlinks in /usr/bin.
how that would help in case of a conflict with original MNE's binaries
becoming available/conflicting?
> You
> coul
Urgh. How about installing the .py to a private directory (under
/usr/share say?) and creating non-suffixed symlinks in /usr/bin. You
could document that the user could/should prefix the /usr/share dir
in their $PATH if they need to rely on the .py names existing,
perhaps even provide a small helpe
I am mentoring packaging of https://github.com/mne-tools/mne-python and
ATM their public python scripts (ATM 10 of them already) carry .py
suffix. At first I blindly recommended to strip those off
(https://github.com/mne-tools/mne-python/pull/865) but the problem is
that there is a non-free orig
17 matches
Mail list logo
