Date: Thu, 25 Mar 2021 16:03:20 +0100 From: Baptiste Daroussin <bapt@FreeBSD.org> To: Olivier Certner <olivier.freebsd@free.fr> Cc: freebsd-ports@freebsd.org Subject: Re: Python 2.7 removal outline Message-ID: <20210325150320.f74kx2uor4dwl5y5@aniel.nours.eu> In-Reply-To: <10693816.1udYB6hd2u@ravel> References: <20210324130347.GA29020@freefall.freebsd.org> <10693816.1udYB6hd2u@ravel>
next in thread | previous in thread | raw e-mail | index | archive | help
--f7e6xagcrslxkxdu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Mar 25, 2021 at 12:02:29PM +0100, Olivier Certner wrote:
> Hi,
>=20
> Maintainer of Tauthon here, and of Pale Moon (for the few hours it lived =
in=20
> the tree in February; but I'm still pushing updates to PR 251117).
>=20
> I find this announcement very much disappointing, because the situation f=
or=20
> ports that need Python 2.7 or similar to build doesn't seem to have chang=
ed at=20
> all. In short, we are just told (again) that they should disappear.
>=20
> But now we are told also that there are exceptions to the general rule. A=
nd=20
> even worse (or better, for the comical effect), that the Chromium excepti=
on is=20
> going to force its agenda on portmgr@, because nobody seems to really kno=
w=20
> when that migration will complete (having quickly studied how it worked o=
ut=20
> for Firefox, I'm willing to bet this will never happen before June, and l=
ikely=20
> will not before the end of this year either). "I love it when a plan come=
s=20
> together."
>=20
> I had hoped that portmgr@ would turn to me (and others in the same situat=
ion)=20
> with at least some way out to allow Pale Moon to go into the ports tree. =
In=20
> its mail, the closest thing I can find is this:
> > - you are of course free to provide your own version of Python 2.7, Tau=
thon
> > and any application using those languages in your local setup, by usi=
ng
> > overlays for example.
> So, if I understand correctly, in its great magnanimity, portmgr@ allows =
us to=20
> do what we want locally. Gosh! That's news. Didn't know I had been violat=
ing=20
> the law for the past 10 years by doing exactly that with my set of patche=
s to=20
> the ports tree (a long way before overlays even existed; that said, I thi=
nk=20
> overlays are helpful, more on that below).
>=20
> And there's more in the same "tone":
> > No excuses. * 3
> You probably were not addressing this to me in particular (at least I hop=
e).=20
> But just in case, did you mean: Excuses for not respecting a non-existing=
=20
> policy?
>=20
> In December last year, I submitted Tauthon with the goals to be able to u=
se it=20
> to build Pale Moon and help others that needed to run 2.7 code despite ph=
asing=20
> out of PSF's interpreter. It was pushed on 2020/12/11. I then submitted a=
n=20
> upstream-approved official version of Pale Moon port, that was pushed on=
=20
> 2021/02/15. It was removed less than 4 hours later, together with Tauthon=
, in=20
> "rage commit" 565350 by antoine@, without any public (or private to me)=
=20
> communication, before or after. Except for one thing: He responsed to my=
=20
> request for explanations by saying: "When we deprecate python 2.7, we als=
o=20
> deprecate all forks of python 2.7.".
>=20
> That also was news to me. Don't know how many ports would have to be remo=
ved=20
> if this rule was followed for all forks of now deprecated projects. I don=
't=20
> think there would be only a few of them. What about the fact that Tauthon=
has=20
> lived 2 months in the tree up to the removal? What about that it was=20
> contributed through a public PR, linked to other Python-related PRs by so=
me=20
> committers? What about that nobody issued a public objection to its prese=
nce=20
> on said PR or on mailing lists? What about that it is still listed *today=
* on=20
> the wiki's WantedPorts page? Never had a single answer on all this. Surel=
y=20
> these must have been signs that what I was doing was very wrong indeed, a=
nd=20
> against a very clear and strong policy, which I should have understood by=
=20
> myself. Idiot me.
>=20
> I'm not going to repeat here the long mail I wrote in response to FUD bei=
ng=20
> spread about Pale Moon (and even Tauthon and Python 2.7 to some extent) b=
y=20
> rene@ and danfe@, and its excruciating details on how deluded they were=
=20
> (still are?). These mails were for committers only, and exchanged on=20
> 2021/02/2{1,2}.
>=20
> I'll just quickly point out the new FUD and inaccuracies, add some facts =
and=20
> opinions to the picture, and wrap up with two possible ways out.
>=20
> > Tauthon is not guaranteed to be compatible with any official
> > Python version so keeping it would just unnecessarily complicate thin=
gs.
>=20
> mandree@ preceeded me, so not going to add much except that Tauthon in=20
> practice lives up to its promise (there are incompatibilities due to the=
=20
> introduction of some Python 3 features, but they are very minimal and har=
d to=20
> trigger; unfortunately for me, Pale Moon's weird build system, inherited =
=66rom=20
> Mozilla, triggered some).
>=20
> As to why it would complicate things, we are left with no clue, especiall=
y=20
> given that Tauthon is not hooked at all into python.mk and that no port=
=20
> currently depends on it (Pale Moon having been removed).
>=20
> > - On a related note, most software using Python 2.7 was already removed
> > from the Ports Tree last year, a lot of it being unmaintained or
> > more or less abandoned upstream.
>=20
> 1. Most is not all, unfortunately. What happens for the rest? Is "Well, l=
et's=20
> pretend it doesn't exist, and shut the contributors up." your response?=
=20
> Seriously?
> 2. Security is a non-issue for build-only dependencies.
>=20
> > - We are indeed faster with dropping Python 2.7 than e.g. Ubuntu, howev=
er
> > more recent Debian/Ubuntu distributions are more and more dropping Py=
thon
> > 2.7 too. This also has to do with how their branching model works, the
> > package set of Ubuntu LTS is determined a few months before the relea=
se
> > itself.
>=20
> Debian is still tolerating Python 2.7 for build-only dependencies in bull=
seye,=20
> which is due to be released imminently, and will be supported until aroun=
d=20
> 2024. Ubuntu 20.04 LTS incorporates it, apparently without restrictions (=
I see=20
> a full suite of packages relying on 2.7 there), and this release will be=
=20
> supported until... April 2025. So, yes, faster by at least 2 years.
>=20
> Surely, we are not organized the same, and do not have the same manpower =
and/
> or money. However, their security teams do not seem to think that phasing=
out=20
> CPython 2.7 right now is of uttermost importance. Some Debian links on th=
e=20
> topic:
> https://tracker.debian.org/pkg/python2.7
> https://wiki.debian.org/Python/2Removal
> I must point out that this last page, although listing interesting links,=
=20
> seems itself seriously outdated, as it is contradicted by facts (e.g., 2.=
7 is=20
> in bullseye, and it is indeed receiving security fixes, see the first lin=
k).=20
> It seems that they have changed their mind in light of needs and demands.=
Food=20
> for thought for portmgr@?
>=20
> And again, there would be no hurry at all for build-only dependencies. Or=
is=20
> there? May I ask on which ground exactly?
>=20
> > As can be seen on [2], multiple vulnerabilities already have
> > been fixed for Python 3.6 to 3.9 this year.
> > [2] https://www.python.org/downloads/release/python-392/
>=20
> I've started looking into these vulnerabilities. Most are simple to=20
> understand, and their patches even readily apply to Tauthon when relevant=
=2E=20
> Going to submit a bunch of them upstream. At least, this is possible with=
=20
> Tauthon, contrary to CPython 2.7.
>=20
> But in the end, I don't think this is really important for the dependent =
ports=20
> issue, since, again, we are talking about build-only dependencies on CPyt=
hon.
>=20
> That was just for the sake of re-establishing a more accurate balance of=
=20
> facts. Given the track record of recent reactions of portmgr@, I'm now no=
t=20
> foolish enough to believe that all that precedes is going to have any vis=
ible=20
> effect on them.
>=20
> Now, for the two possible ways out, I'm still having some hope (but frank=
ly=20
> not that much).
>=20
> 1. Add the infrastructure to have build-only dependencies. I've proposed=
=20
> changes to that end (https://reviews.freebsd.org/D28946). In addition to =
the=20
> comments in the review, bapt@ rightfully pointed out that 'make install' =
would=20
> still be possible to run for ports listed in NORUNTIME. I acknowledge tha=
t=20
> this is indeed a problem in the current problem, but think it could be so=
lved=20
> technically (e.g., forbidding 'make install' for those ports, but allowin=
g it=20
> when building a dependent port through an environment variable, and remov=
ing=20
> the install after the build). Which reinforces my thinking that the "prob=
lem",=20
> whatever that is, is not technical, but human. Overall, portmgr@ doesn't=
=20
> really seem to be interested in this solution (got short reactions such a=
s=20
> "with RESTRICTED, we don't need this", or "this would be a precedent", in=
deed=20
> a useful one if you're asking me).
>=20
> 2. Leverage overlays to provide additional repos, a bit like AUR for Arch=
=2E=20
> Here I'm in fact building on top of one of bapt@'s ideas. Sounds great fo=
r=20
> publishing ports that are not in the official tree. But not necessarily f=
or=20
> package building: I personally won't commit to maintaining a separate bui=
ld=20
> cluster for all arches and supported FreeBSD versions, in the short term =
at=20
> least.
I really think we should as a project move forward to that direction, it do=
es
not even need to be driven by protmgr or even drive by any @freebsd.org
I would argue here that it is even more interesting to go the gentoo way tr=
y to
provide a tool to just server as a directory of available overlays
with https://github.com/freebsd/poudriere/pull/798 and
https://github.com/freebsd/poudriere/pull/797 it is even easier to public a
light repo per overlay.
>=20
> I re-read portmgr@'s charter (https://www.freebsd.org/portmgr/charter/). =
I=20
> wish it contained points about proper planning, communication and helping=
=20
> maintainers and committers instead of destroying their work without notic=
e,=20
> even for "niche" ports. Perhaps it doesn't because this was implicit or t=
aken=20
> for granted. In which case, in light of recent events, it may be a good t=
ime=20
> to revise it.
I will only here answer about the quality of the communication of portmgr, =
yes
there is room of improvement in general in the current portmgr team as of h=
ow we
do communicate about plans and policy and we are working on it.
Best regards,
Bapt
--f7e6xagcrslxkxdu
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAmBcpjUACgkQY4mL3PG3
Plqmrg//XTkyosN/d4Y89RHrrqtZTl2T4t7suQvdH7xIYkHrE/OAFF28zQtX65xu
yWT6COpxp2E0KCq2DXLXMmuJfHAWcVxaISI4MOc3n3Ow6H7HlGOCpZTsLXpq7uYv
lza5OovH//rELv9btdgyItKJ+BM6P2s9/5uraN0F38bH++WvM/xp3/0lVmBxS2SB
uPO6f0fsKY2xPEpNg/YuowtVDooQQrNk606Bm81DCBe/EXKkjR6L54xb1GyJGTnt
Gcb+fNAOiOKws35E4l4tuiWupu6C17mrv5422sODrNyTdqNeaz5nvNd/b/eLO6kW
f7ky30Dvvs5MOE5cn0jGx6aLidWnoM5cIc575PTouk0UIK4LYOl5hm26chK4+v+c
YPzE4An5AOATGZ5r9dJw9NiSL2eZdhqmu8aZ69ehxj3v9arvcpNq2kgFv6j/HFY0
/Z3mzZidQyZWzX3rfjNoaBRAojl6tjL4tjv/xyBpiGrIrnPfF6+TNZuJRWhcLoqo
TyhCStGjeA5v1LCFHGOmw8XtrPEeTjh3X7Ry6nIBufh/2/X7dkgE4jl/64NrRQHs
/O39vZuyXU2RCMNreDE75sGEBYn6oITWt1Z1ncj7eR9ljsHOOzF+C44m//q0861t
Zg0bX+rjKWVmp8N1mCEA0ITrz5eBswnBmTp1xZdJe+FJHd1ZldI=
=DPqu
-----END PGP SIGNATURE-----
--f7e6xagcrslxkxdu--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210325150320.f74kx2uor4dwl5y5>