Thanks for your reply, Niels. You made a very good point: the byte-compile step can be moved to post install script, which could help us to reduce the package size. I will consider this.
Cheers, Hang -----Original Message----- From: Niels Thykier <ni...@thykier.net> Sent: Thursday, May 9, 2024 18:39 To: Hang Lei <hang...@microsoft.com> Subject: [EXTERNAL] Re: dh_clean should not remove __pycache__ folder by default [You don't often get email from ni...@thykier.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Hi Hang I forgot to CC you direct in my previous reply (in case you were not subscribed, which people are not by default). Original reply included below. Please be sure to include 1070...@bugs.debian.org in your reply if you want it to go in the bug tracker (I have Reply-To accordingly) Best regards, Niels ---- Control: tags 1070794 wontfix # Solution options provided below. # (BTS processing instructions have to go in the top) On Thu, 9 May 2024 09:20:01 +0000 Hang Lei <hang...@microsoft.com> wrote: > Package: debhelper > Version: 13.11.10 > > Dear Maintainer, > > I'm writing to discuss a change introduced in debhelper 13.10.10: this > PR<https://salsa.debian.org/debian/debhelper/-/merge_requests/120> fixes > #1048890<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1048890> by > deleting the __pycache__ folder. > > [...] > > Considering the impact on performance, I believe that removing the > __pycache__ directory may not be beneficial. Could we explore the possibility > of reverting this change? > > Thanks for your time and consideration. > > Related issue: [Packaging] Add Ubuntu 24.04 Noble Numbat support by > bebound * Pull Request #28888 * Azure/azure-cli > (github.com)<http://https/ > %3A%2F%2Fgithub.com%2FAzure%2Fazure-cli%2Fpull%2F28888&data=05%7C02%7C > hanglei%40microsoft.com%7Cbfe530c3f0894af11e2008dc70144c14%7C72f988bf8 > 6f141af91ab2d7cd011db47%7C1%7C0%7C638508479793845869%7CUnknown%7CTWFpb > GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 > %3D%7C0%7C%7C%7C&sdata=X9Hg%2B9O97HcY7Mg4yCe8uYZprFTA8a684qsmQfDyqqM%3 > D&reserved=0> > > Cheers, > Hang Hi Hang Thanks for reaching out. :) No Debian package ships `.pyc` files directly in the `.deb`. Instead they generate them during installation. I am not super well-versed in this area, so I cannot be fully helpful on all of the rationales behind the decision to byte-compile on install (and clean up on removal). You would have to ask the Debian Python Team / Debian Python Policy maintainers if that rationale is important. As I recall, it involves (or involved) cases like people running python code as root, reproducible builds, multiple interpreter support (including embedded interpreters) and special cases in that ballpark. What I do know, is that this byte compilation for Debian packages is generally triggered by using `dh_python3` from the `dh-python` package for python3 files[1]. The `dh_python3` helper is *not* enabled by default. With modern debhelper versions adding `dh-sequence-python3` to Build-Depends would do. Older versions of `debhelper` would require a `dh ... --with python3`. Since the package in question does not seem to install the python files in the "standard" locations (I noted an `/opt` in the GitHub PR), you may have to consult the `dh-python` documentation for having it set up the recompilation correctly. See https://salsa.debian.org/python-team/tools/dh-python/-/blob/master/dh_python3.rst?ref_type=heads (heading "private dirs" seems relevant) That documentation also has sections for exceptions to the byte compilation via the `bcep` files. Like if certain files can only be compiled with a given version of python (etc.). This is the only solution I can offer you with the current Python landscape in Debian. If you want to change that landscape, I am afraid I will have to ask you to raise the concerns with the Python team and they are the authority on this topic. Because it is not my jurisdiction and I cannot offer to be middleman in challenging the landscape, I have tagged this bug as `wontfix`, since it is the closest tag we have for this case. I hope it was helpful and enable you to restore the original performance. Best regards, Niels [1]: Historically, there was also a `dh_python`, which may be relevant if you still support python2 and Debian/Ubuntu releases that still have `python2`. That is probably so old that it only works with `dh ... --with python`.
