public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
* Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)
@ 2024-03-27 21:18 Brian Inglis
  2024-03-28 17:49 ` Jon Turney
  0 siblings, 1 reply; 20+ messages in thread
From: Brian Inglis @ 2024-03-27 21:18 UTC (permalink / raw)
  To: cygwin-apps

On 2024-03-27 14:07, Jon Turney via Cygwin-apps wrote:
> On 24/03/2024 18:51, Brian Inglis via Cygwin-apps wrote:
>> On 2024-03-24 11:46, Jon Turney via Cygwin-apps wrote:
>>> On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote:
>>>> On 24/03/2024 15:07, Jon Turney wrote:
>>>>> On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote:
>>>>>
> [...]
>>
>> Not sure why my source package nghttp2 shows python install packages, when 
>> they were dropped after 1.43 IIRC: build deps no longer include python/-devel?
> 
> If you haven't taken any specific action to retire the python-3x-nghttp2 
> packages, the existing ones will continue to be available indefinitely.
> 
> Firstly, it seems there's a question here about what are upstream's plans for 
> the users of the python bindings for this library.
> 
> Are they supposed to migrate to some alternate bindings maybe available from a 
> separate repo? Or are they just out of luck?

SOL! Dropped them in 1.52, probably why 1.31.0..1.51.0 are hanging around.

>> And why does that nghttp2 source package show a dozen archived source 
>> versions, when its installed packages have only three?
> 
> The simple answer to that is we retain the source package for all available 
> install packages.  This seems essential for an open-source project.
> 
> Now, as to why there are so many installable packages, this is the intersection 
> of a couple of unfortunate issues.
> 
> 1. 'python3-nghttp2' is an "old-style" obsoletion package, where the package 
> exists, but is of category _obsolete, and requires the replacement package.
> 
> These are terrible, because we can't remove the obsolete package because that's 
> what records the fact of obsoletion.
> 
> I actually have some code for calm to internally convert that to a "new-style" 
> obsoletion, where the replacement package itself records the obsoletion (i.e. 
> python36-nghttp2 obsoletes: python3-nghttp2), which it continues to remember 
> about even after the package which contains that obsoleting is expired.
> 
> Once that's done, all those "old-style" obsoletion packages lingering in our 
> package repository can be removed (along with their corresponding source).
> 
> But I still need to do some testing before that can be deployed.
> 
> (However, all that's probably not what's actually wanted with python packages: 
> it's preferable to have python3-foo be a virtual package which pulls in 
> python3x-foo, where python3x is the current python, so that scripted installs 
> can be written which ask for python3 and python3-foo and continue to work while 
> x changes...)
> 
> 2. We haven't purged old python versions for a long time, so e.g the python36 
> binding packages are still lingering.
> 
> As you can see, I'm just now getting around to looking at expiring python36, 
> which eventually should lead to python36-nghttp2 being expired (insert some 
> observations about how it doesn't have to be me doing these things here)...
> 
>> Feel free to purge as appropriate, or tell me what to add to cygport, hints, etc!
> 
> So, the long list of source versions will hopefully be reduced in the fullness 
> of time...

Could I just add to nghttp2.cygport that nghttp2 obsoletes 
python{2{,7},3{,6,7,8,9}}-nghttp2?
Does this have to remain in the cygport forever to avoid keeping nghttp2 vx.x.x 
around?

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

^ permalink raw reply	[flat|nested] 20+ messages in thread
* Bonfire of the Packages
@ 2023-09-24 12:32 Jon Turney
  2024-03-24 14:07 ` Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages) Jon Turney
  0 siblings, 1 reply; 20+ messages in thread
From: Jon Turney @ 2023-09-24 12:32 UTC (permalink / raw)
  To: cygwin-apps


Generally, we have a large number of old, unmaintained packages.

The policy [1] has always been "Packages without an active maintainer 
may be pulled from the distribution.", but not actively enforced (in 
fact prior to 2022, this used to say "are pulled", but I moderated the 
statement, just to reflect reality).

I guess what's needed is an automated process which removes unmaintained 
packages, after some period of time in that state.

I'm somewhat ambivalent about doing that, as they are probably of some 
use, but on the hand I don't think our users are best served providing 
very old packages with unknown numbers of bugs, security problems, etc., 
or which are unsupported upstream.

So, to start with, please give your nominations for the chopping block 
here, or volunteer to rescue them via an ITA.

It would be nice to do this in an evidence-based, data-driven manner, 
prioritising keeping packages that people actually use, but that 
involves building something to collect that data, which I am not 
optimistic about being forthcoming.


Here's my personal list:

* python

After python27 (the last python2 version, which has been sun-setted 
since 2020), both python36 and python37 should be removed (after 
rebuilding any python-* package which don't currently provide 3.8, 3.9 
versions)

* gcc-tools-epoch{1,2}-{autoconf,automake}

These were only relevant to people making patches for versions of gcc 
which are now historical.

* wxWidgets 2.8?

* vte (soverion 9) (as opposed to soversions 2.90 and 2.91)

* llvm3.5 (only depended on by old clamv versions)

* glade2/glade3 should be obsoleted by glade?

* php

We're currently shipping 7.3, which was out of support Dec 2021.

* X11 DEs

There's a large number of X11 Desktop Environments (list at [2]).

I think we should remove the GNOME and KDE DEs, as they are heavyweight 
and do not perform very well under Cygwin.  Ideally the LXDE/MATE/Xfce 
DEs would get a refresh, but it seems unlikely...

(note this means the desktops, not the applications, although our KDE
and GNOME application stacks also need work to be brought up to date)

There's also some GNOME2 and KDE4 era stuff, which is probably all 
obsolete and can be removed.


[1] https://cygwin.com/packaging-contributors-guide.html#submitting
[2] https://x.cygwin.com/docs/ug/using.html#using-starting-session

^ permalink raw reply	[flat|nested] 20+ messages in thread
end of thread, other threads:[~2024-04-19 12:16 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-27 21:18 Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages) Brian Inglis
2024-03-28 17:49 ` Jon Turney
2024-03-28 19:08   ` Brian Inglis
  -- strict thread matches above, loose matches on Subject: below --
2023-09-24 12:32 Bonfire of the Packages Jon Turney
2024-03-24 14:07 ` Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages) Jon Turney
2024-03-24 17:31   ` Marco Atzeri
2024-03-24 17:46     ` Jon Turney
2024-03-24 18:51       ` Brian Inglis
2024-03-27 20:07         ` Jon Turney
2024-03-28 17:50       ` Jon Turney
2024-04-18  6:01         ` Ake Rehnman
2024-04-19 12:16           ` Jon Turney
2024-03-28 17:50       ` Jon Turney
2024-03-29 18:32         ` David Rothenberger
2024-03-30 15:25           ` Jon Turney
2024-04-01 17:16             ` David Rothenberger
2024-04-02 14:38               ` Jon Turney
2024-04-02 14:58                 ` Takashi Yano
2024-04-05 12:46                   ` Jon Turney
2024-04-05 23:17                     ` Takashi Yano
2024-04-01 15:22       ` Jon Turney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).