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

Re: [Python-modules-commits] [python-cpuinfo] 02/02: Import Debian changes 3.0.0-1




On April 17, 2017 12:20:36 PM EDT, Mattia Rizzolo <mattia@debian.org> 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 just like this), mainly boilerplate, that simply loads the
>> entrypoint from the main module and nothing else?
>
>I think quite a lot of cases are better off without any /usr/bin/foo
>installed, and have the user just call it with `python[3] -m foo`
>instead.
>It's up to the maintainer, of course.
>
>But otherwise yes, I think a separated package is better.
>
>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... This is just a case.
>
>> that seems overkill
>> to me (and probably not only to me, given how much discussion there
>> was on d-devel about small node packages)
>
>Well, to me it seems we either resigned about this situation, or
>stopped
>cared, considering how many node packages appeared in the last months
>without any pointless flame about it (personally, I resigned for now).

The node packages are an entirely different issue.  Separate binaries in cases like this seem gratuitous to me as well.

Replicating the upstream package split (node) is not at all like Debian splitting up a single upstream package.  We should only do it when needed.  I'm not convinced it is for this case.

Scott K


Reply to: