#Debian patching of python

1 messages · Page 1 of 1 (latest)

swift umbra
#

Can you clarify what you are looking for in:

I would say the issue is the lack of a Debian policy to address these situations, if Debian has policies that force the maintainers to make such invasive modifications to software, they should require a discussion to be started with the project upstream asking for guidance and recommendations on how to achieve the desired behavior, to minimize the negative impact the downstream patching will have.

lament radish
#

I think Debian should have a policy requiring package maintainers to start a discussion with the upstream if they have to make such modifications.

#

So the upstream can either 1) provide an official mechanism to acomplish what the downstream packager is trying to do, or 2) adivise how to patch, in order to mitigate the negative impact.

swift umbra
#

I guess the biggest question is why sysconfig-debian-schemes isn't applied. I'm trying to find the backstory on that.

lament radish
#

That patch alone is not suficient, but it's at least half of it.

#

And allows us to write Debian specific logic without depending on distutils.

#

The missing bit is get_preferred_scheme, which should return the scheme Debian wants to be used by normal installers.

swift umbra
#

OK, from my PoV, at the time all of these decisionswere made, barry and doko were core-devs. So we assumed they knew what they were doing, and making the decisions in the interest of Core cPython

lament radish
#

I kind of understand, but it fells like a side-channel to me.

#

It certainly did not give the opportunity for all CPython devs to weigh in.

#

I feel like if that hapenned, someone might have pointed how that sysconfig needs to be patched.

#

Currently, we are in a very precarious state, as distutils is deprecated.

#

I am not putting the blame on anyone, as I understand how these things happen, I am just saying there needs to be more communication.

swift umbra
#

Hrm, I can't even find get_preferred_scheme

lament radish
#

It's new in 3.10, but there was a private function previous IIRC

swift umbra
#

Ah, yeah, I've seen this before

#

been meaning to catch up on those threads...

lament radish
#

hopefully you could make a plan for the distutils deprecation ASAP, so that we can start updating the logic in projects that need to work around the Dbian patching

#

otherwise we will be in a very bad situation

#

we have ~1 year for 3.12

swift umbra
#

So where does this actually affect you?

lament radish
#

which is actually not that much, so as soon as we fix this, less issues we will have

swift umbra
#

What was broken?

lament radish
#

meson for eg. needs to work around this

#

because it needs to install Python modules, and does not use distutils

#

the current code is getting the paths from distutils, because we cannot rely on sysconfig

swift umbra
#

Yeah, I suspect that'll be an issue in any new post-distutils installers

lament radish
#

yes

#

the thing is that nobody should be using distutils

#

but they need to, as the inforation that Debian reports on sysconfig is incorrect

#

I caught it early on, bur their previous patching was broken and broke Github Actions Ubuntu runners for eg.

#

I only caught it because I happen to have a project that needs meson master 🙃

#

but none of this would have happen if sysconfig was not broken on Debian

swift umbra
#

Yeah

#

So, I applied the equivalent of sysconfig-debian-schemes to pypy3 in Debian, a while ago, to make virtualenv behave properly

#

It must have had specific hacks to work correctly without it on cpython

lament radish
#

btw, do you have any feedback on my post? is there anything inacurate?

swift umbra
#

I'd prefer you pointed to Debian's policy rather than Christian's rant

#

Nobody should have to wade through that pile of 💩

lament radish
#

it took me like a week to write and I have dyslexia, so I haven't been able to actually read properly it through start to finish

#

I think Christian's gist is relevant, but I can update it to also link to Debian's policy

#

I acknowledge that currently it is only representing one side

swift umbra
#

And was full of legal threats and crazy-stuff

#

Your interpretation of /usr and /usr/local is new to me, I found that interesting.

#

I need to think about that for a bit.

#

The practical thing here is that debian considers /usr to belong to the package manager (dpkg), with the exception of /usr/local. Your post didn't explain that.

lament radish
#

well, the thing is that the FHS is not really prepared for these situtions

#

IMHO, Python should not be putting user (or sysadmin) installed packages in /usr

#

but from my interpretation, it is OK

swift umbra
#

/usr is where programs traditionally live

#

Why should Python be different?

lament radish
#

though I would really prefeer we had a different solution

#

because it's a Python provide mechanism for customization

#

Python packages are not programs per se

swift umbra
#

I don't think that's a problem unique to Python

lament radish
#

yeah

swift umbra
#

But rather that Unix may not be perfect for the modern world

lament radish
#

I have rammed through it, and I don't think it provides a good way to do this

#

hence my option that doing it is OK

#

it will divert to ~/.local when /usr is read only

swift umbra
#

Anyway, the rest of your technical description was spot-on, to me.

lament radish
#

if there's anything I can help with, please let me know

swift umbra
#

Same 🙂

lament radish
#

anyway, even though I disagree with Debian's approach to this issue, I totally get it, I just wish everything was actually patched properly 😅

#

but optimally, Python should have a mechanism for this so that dowstream packagers don't need to deal with it!

#

🤞

swift umbra
#

Yeah. Carrying patches sucks for everyone, especially when there isn't agreement in them