On 04/17/2017 06:20 PM, Mattia Rizzolo wrote:
> I'm just thinking about how annoying is now changing the /usr/bin/foo
> from the python2 to the python3 package, and in the meantime stuff
> started to (build-)depend on it only for the /usr/bin/foo, stuff which
> may or may not be easy to detect...
On April 17, 2017 12:20:36 PM EDT, Mattia Rizzolo wrote:
>On Mon, Apr 17, 2017 at 12:12:11PM -0400, Sandro Tosi wrote:
>> are we really suggesting to create a separate binary package, for a
>> single script, not even 400 bytes (in py-cpuinfo case, but i bet
>there
>> are more
On Mon, Apr 17, 2017 at 12:12:11PM -0400, Sandro Tosi wrote:
> are we really suggesting to create a separate binary package, for a
> single script, not even 400 bytes (in py-cpuinfo case, but i bet there
> are more just like this), mainly boilerplate, that simply loads the
> entrypoint from the
are we really suggesting to create a separate binary package, for a
single script, not even 400 bytes (in py-cpuinfo case, but i bet there
are more just like this), mainly boilerplate, that simply loads the
entrypoint from the main module and nothing else? that seems overkill
to me (and probably
Hi Mattia,
On Sun, Apr 16, 2017 at 10:50:15PM +0200, Mattia Rizzolo wrote:
> > AFAIC, I happily use pytest or sphinx via their respective python[3]-
> > pytest
>
> There is a peculiar thing about pytest: the version of python used
> matters. That's different than most python /usr/bin/* things.
>
On Sun, Apr 16, 2017 at 09:07:09PM +0100, Ghislain Vaillant wrote:
> So what you guys are proposing is to introduce a new wrapper script, in
> its own binary package, whose name is not endorsed by upstream, and
> which will end-up completely Debian specific.
>
> Am I really the only one in this
On Sun, 2017-04-16 at 18:09 +0200, Mattia Rizzolo wrote:
> On Sun, Apr 16, 2017 at 05:50:54PM +0200, Hugo Lefeuvre wrote:
> > I introduced an additional binary package for this script because I thought
> > people cold have found it useful. But, right, everything considered I should
> > better drop
Hi,
2017-04-16 18:09 GMT+02:00 Mattia Rizzolo :
> Surely I'm not the only one who would consider moving the file back to
> python3-cpuinfo a step backward…
>
ack. I like solo binary package for /usr/bin/* tools too.
--
Best regards
Ondřej Nový
Email: n...@ondrej.org
PGP:
On Sun, Apr 16, 2017 at 05:50:54PM +0200, Hugo Lefeuvre wrote:
> I introduced an additional binary package for this script because I thought
> people cold have found it useful. But, right, everything considered I should
> better drop it.
Wait a second before dropping this..
What would be the
Hi,
> Also, the `cpuinfo` utility can be invoked with `python[3] -m cpuinfo`
> according to the upstream README [1]. So, I am not convinced of the benefit
> of introducing an additional binary package (py-cpuinfo) for something the
> library packages already provide.
I introduced an additional
Also, the `cpuinfo` utility can be invoked with `python[3] -m cpuinfo`
according to the upstream README [1]. So, I am not convinced of the
benefit of introducing an additional binary package (py-cpuinfo) for
something the library packages already provide.
[1]
well, the py- prefix seems wrong as well (and not part of the recommendation)
On Sun, Apr 16, 2017 at 5:44 AM, Ondrej Novy wrote:
> Hi,
>
>
> 2017-04-14 20:25 GMT+02:00 Sandro Tosi :
>>
>> why the cli tools are in a separate packages, instead of being inside
>>
Hi,
2017-04-14 20:25 GMT+02:00 Sandro Tosi :
> why the cli tools are in a separate packages, instead of being inside
> the py3k package (as it seems to suggest it uses the python3
> module to work)?
>
because it's one of our team recommendation:
On Thu, Apr 13, 2017 at 6:10 AM, Hugo Lefeuvre
wrote:
> +Package: py-cpuinfo
> +Architecture: all
> +Depends: python3-cpuinfo,
> + ${misc:Depends},
> + ${python3:Depends}
> +Description: Python script for getting CPU info
> + py-cpuinfo provides a
14 matches
Mail list logo