1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL

  • Re: Seeking consensus on file conflict between python3-proto-plus and n

    From Andrey Rakhmatullin@21:1/5 to Yogeswaran Umasankar on Tue Jun 11 09:00:01 2024
    On Mon, Jun 10, 2024 at 06:40:02PM -0400, Yogeswaran Umasankar wrote:
    There is a file conflict between python3-proto-plus and nanopb. The
    conflict arises due to both packages has a file at /usr/lib/python3/dist-packages/proto/__init__.py [0]. I am maintaining python3-proto-plus, and I am seeking guidance.

    The module name "proto" is an integral part of the python3-proto-plus package. Renaming the "proto" module in python3-proto-plus would significantly impact future dependent packages.

    It appears that nanopb's use of the module name "proto" does not align
    with the conventional identification of a Python module.

    What do you mean? It does look like a Python module to me. It's very
    likely that it should be a private one though, but I see you already asked
    the maintainer about that.

    I have attempted to reach out to the nanopb maintainer to discuss this
    issue, but I have not yet received a response. In case the maintainer is
    MIA, should I proceed with renaming the "proto" module in nanopb to "nanopb-proto"?

    No, it will make it useless.
    I don't see a good way forward that doesn't involve NMUing nanopb.


    --
    WBR, wRAR

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmZn9CctFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh HoUQAKsmcgwaVD4mSD8A04xFRMbCL9cJ6yTwl8PiSbQldp9nzr00OPRnSfzXIaVP 9YqlNEUZ6j/iFyPcDMfVrVu71AJNB9dj9lwo1Hcz3/2nJO0S0aZgWyip39bWuKM8 xvF6p1Ue95Vtz0EJmHa9rfVUPnvOAjDMEmptb/b3mv0NgTw+5cQF8mQXTwPXXbor VZBjTKOroaCRX8WrfMDGHb0ntKlo2/Yr233jI+God+TZ8vaASfGi/UIHxfKjeXEd iJNMeTa9Cj3BNwcxonTPvxA41DYtjVtMol8ciBrSi2Ao+UINZyyH13jszkL3fQpq HrldyLwp9KmYVsc9D7rE+RiPQIFAVLpMsYW8XyWr5R1bFRl+J/NvyZ/zMRo8glzM 0BNaM21NhWiuUwFieYv2AEzTQHLi+0vax3O7SfivsVGgqR9tXSGPSty+cw3YH9eg J7cYLajD6m3U04a4r8AmtA5rYsw8mUyiekQugSUVQ9qe0Y+8QLTYWZrweYk9wYNm tEZw7LxIXTt534/gh4I2eyaArvIoiLB4RWcSQoIDibZVdot2PpXnoR7K/Vz4Kj4s eZ2V8Tjr2Xzjy6Dte/e7TPx2OFPvCj0PRXQPdfyIHihVc2Fs+ORvUQG8pXnyt1nc mA/3j5oW2WthCbpf+4nbP7ISpih2HBGINHdK7nUPRrE/ehtt
    =U5CI
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Helmut Grohne@21:1/5 to Yogeswaran Umasankar on Tue Jun 11 14:50:01 2024
    Hi Laszlo and Yogeswaran,

    I'm explicitly adding Laszlo to Cc to increase the chances of him
    chiming in.

    On Mon, Jun 10, 2024 at 06:40:02PM -0400, Yogeswaran Umasankar wrote:
    There is a file conflict between python3-proto-plus and nanopb. The
    conflict arises due to both packages has a file at /usr/lib/python3/dist-packages/proto/__init__.py [0]. I am maintaining python3-proto-plus, and I am seeking guidance.

    Thank you for going the extra mile and resolving this constructively and consensually.

    The module name "proto" is an integral part of the python3-proto-plus package. Renaming the "proto" module in python3-proto-plus would significantly impact future dependent packages.

    I agree with this assessment. At the same time, I note that "proto" is a
    fairly generic name. Even though it seems unlikely that upstream would
    want to change it, I think telling them would be useful still. It
    definitely is conceivable that another project would later try to also
    use this module name and therefore it is best to avoid it.

    It appears that nanopb's use of the module name "proto" does not align
    with the conventional identification of a Python module. Given this, it
    might be plausible to make this module private within the nanopb
    package. This adjustment could potentially resolve the conflict without affecting the dependent packages.

    Yes. In particular, I could not locate external uses of nanopb's proto
    module. chromium and firefox also use this module name though my
    impression is that they have another conflict on this name again arguing
    in favour of not using it at all.

    I have attempted to reach out to the nanopb maintainer to discuss this
    issue, but I have not yet received a response. In case the maintainer is
    MIA, should I proceed with renaming the "proto" module in nanopb to "nanopb-proto"? As one of the team members, I am willing to implement
    this change if it is deemed the best solution.

    I recommend that you send a patch to the bug and give Laszlo two weeks
    before proceeding to NMU in the absence of a reply as the proposed
    change is a bit intrusive.

    Helmut

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Richter@21:1/5 to Yogeswaran Umasankar on Tue Jun 11 16:00:01 2024
    Hi,

    On 6/11/24 07:40, Yogeswaran Umasankar wrote:

    It appears that nanopb's use of the module name "proto" does not align
    with the conventional identification of a Python module. Given this, it
    might be plausible to make this module private within the nanopb
    package. This adjustment could potentially resolve the conflict without affecting the dependent packages.

    From a quick glance at the package, not completely. It seems the
    "proto" module is used by the generator only, which is called as a
    plugin from Google protoc, so I'm not sure it can be taken fully private.

    I think it should be possible to rename this module though with little
    adverse effect.

    The standard invocation certainly is convoluted[1], and given that CMake
    is usually not the first choice for cross compiling in embedded
    environments, I also expect that there will be a lot of users rolling
    their own -- but I don't see the name of the module used on that command
    line, only the name of the plugin.

    The script tries to do a relative import and provides fallback code if
    that is not yet supported in the Python interpreter (which it is since
    2007), so that might explain why the module is not up to current
    conventions.

    Simon

    [1] https://github.com/nanopb/nanopb/blob/master/extra/FindNanopb.cmake

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw@21:1/5 to kd8mbd@gmail.com on Mon Jun 17 07:30:01 2024
    Hi all,

    On Sun, Jun 16, 2024 at 11:33 PM Yogeswaran Umasankar <kd8mbd@gmail.com> wrote:
    Thank you all for your suggestions. Since there has been no response
    from Laszlo, I will implement the recommendations from your suggestions.
    Thanks for your patience. I'm here just running back and forth. Going
    to note nanopb upstream this afternoon.
    Let's see what their response will be, but if you have a patch
    meanwhile let me know and I will forward it to them.

    Regards,
    Laszlo/GCS

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw@21:1/5 to gcs@debian.org on Tue Jun 18 17:50:01 2024
    Control: forwarded -1 https://github.com/nanopb/nanopb/issues/977

    Hi,

    On Mon, Jun 17, 2024 at 7:28 AM László Böszörményi (GCS) <gcs@debian.org> wrote:
    Thanks for your patience. I'm here just running back and forth. Going
    to note nanopb upstream this afternoon.
    As promised, I reported it to upstream yesterday. Turns out it was my
    bad. Corrected package version will be uploaded soon.

    Regards,
    Laszlo/GCS

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)