public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Yaakov Selkowitz <yselkowitz@cygwin.com>
To: cygwin-apps@cygwin.com
Subject: Re: Putting packages up for adoption
Date: Thu, 26 Mar 2020 03:19:27 -0400	[thread overview]
Message-ID: <eaa84baf9bad787ab6f1c2078c77dcd383f38597.camel@cygwin.com> (raw)
In-Reply-To: <8de4bc18-86d2-4f3b-e2c4-8d1cd5792a23@gmail.com>

On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:
> Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
> > To that end, in the best interest of the community, please consider my
> > packages up for adoption.  I don't expect that any one person will take
> > all of them; some are obsolete and due for removal anyway, some should
> > be picked up as soon as possible, and others might just end up
> > bitrotting if nobody is interested in them.  However, in whatever there
> > is interest (or need), hopefully what is there now will serve as a
> > strong foundation to on which to continue to build.
> 
> I am considering to take over python, and I am building 2.7.17 and 3.8.2
> to see how complicate it is.
> 
> One question on the cygport
> 
>          # see PEP 394
>          dosym python${slot}.exe /usr/bin/python
>          dosym python${slot}.exe /usr/bin/python2
> 
> do you see any problem to use alternatives for the same scope ?

The reason I avoided using alternatives for this was consistency. 
Since we don't build our packages in a clean (ch)root, if a maintainer
had such created such symlinks themselves, and they were to be picked
up during a build (very likely), or simply relied upon by scripts which
typically hardcode a generic version (very common), it would lead to a
package which would not run identically, or possibly not at all, on
other users' systems.  I would discourage using alternatives here.

Of course, in the meantime, the Python world has moved very strongly to
3.x, to the point that upstream has dropped it, Fedora has mostly
deprecated it, and /usr/bin/python is now a symlink to python3 provided
by a separate package.  However wrt Python 2, the only version we care
about at this point is 2.7, and while it's lifespan is limited, it is
still needed.

I would suggest the following:

* python2-2.7.z continues to provide all '2' symlinks.

* python38 be updated to 3.8.2, and 3.8 be designated the next default
'python3' version (with the '3' symlinks continued to be kept
separate), and adjust python-wheel.cygclass accordingly.

* Similarly, a separate package (in Fedora it's called 'python-
unversioned-command') provide unversioned symlinks, pointing to 2.7 for
now (for compatibility).

* Anything currently dependent on 'python' or 'python2' should either
be dropped if no longer needed, switched to 3 is possible, otherwise
rebuilt.

* Drop 2.7 from the "default" version set in python-wheel.cygclass, and
only build those modules that are actually needed by other things by
specifying "all".

* Once that's done, look at what's still depending on /usr/bin/python
('python-unversioned-command'), and based on that decide when that can
be changed to point to python3.

HTH,

--
Yaakov



  reply	other threads:[~2020-03-26  7:19 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-20  3:47 Yaakov Selkowitz
2020-03-20  5:04 ` Marco Atzeri
2020-03-20  6:05   ` ASSI
2020-03-20 10:19     ` Corinna Vinschen
2020-03-20 10:23   ` Corinna Vinschen
2020-03-20  8:13 ` Hamish McIntyre-Bhatty
2020-03-20  8:28   ` Marco Atzeri
2020-03-20  9:29 ` Jan Nijtmans
2020-03-20 10:22   ` Corinna Vinschen
2020-03-22 22:34   ` Yaakov Selkowitz
2020-03-23 12:07     ` Jan Nijtmans
2020-03-23 15:45       ` Yaakov Selkowitz
2020-03-23 21:04         ` Jan Nijtmans
2020-03-23 23:37           ` Yaakov Selkowitz
2020-03-24 11:41             ` Jan Nijtmans
2020-03-24 13:51               ` Yaakov Selkowitz
2020-03-24 14:11                 ` Jan Nijtmans
2020-03-24 14:24                   ` Yaakov Selkowitz
2020-03-24 19:27                     ` Jan Nijtmans
2020-04-01  9:10                       ` Jan Nijtmans
2020-03-20 10:19 ` Corinna Vinschen
2020-03-20 12:11   ` Jon Turney
2020-03-24 20:19   ` Andrew Schulman
2020-04-01 20:58     ` Yaakov Selkowitz
2020-04-02  7:35       ` Corinna Vinschen
2020-07-21  0:33         ` Andrew Schulman
2020-03-20 12:09 ` Jon Turney
2020-03-21 12:47   ` Thomas Wolff
2020-03-21 14:10     ` Jon Turney
2020-03-20 12:31 ` Marco Atzeri
2020-03-20 17:32   ` Achim Gratz
2020-03-20 19:16     ` Hamish McIntyre-Bhatty
2020-03-20 19:22     ` Yaakov Selkowitz
2020-03-20 20:30     ` Marco Atzeri
2020-03-22 15:34       ` ASSI
2020-03-22 16:36         ` ASSI
2020-03-22 19:49           ` Yaakov Selkowitz
2020-03-22 20:39             ` Achim Gratz
2020-03-22 19:03   ` Achim Gratz
2020-03-23 17:14     ` ASSI
2020-03-23 23:06       ` Marco Atzeri
2020-03-20 16:17 ` Doug Henderson
2020-03-21 14:12   ` Jon Turney
2020-03-26  5:54 ` Marco Atzeri
2020-03-26  7:19   ` Yaakov Selkowitz [this message]
2020-03-27 17:52     ` Marco Atzeri
2020-03-27 20:52       ` Yaakov Selkowitz
2020-03-28  3:33         ` Marco Atzeri
2020-03-30  6:01           ` Yaakov Selkowitz
2020-03-27 17:53     ` Marco Atzeri
2020-03-27 18:32       ` Hamish McIntyre-Bhatty
2020-03-27 19:10         ` Yaakov Selkowitz
2020-03-27 20:02           ` Hamish McIntyre-Bhatty
2020-04-10 12:52     ` Python - plan & execution Marco Atzeri
2020-04-23 21:54       ` Yaakov Selkowitz
2020-04-27 14:34         ` Jon Turney
2020-05-25  4:52           ` Marco Atzeri
2020-05-25 13:43             ` Jon Turney
2020-05-25 23:45             ` Yaakov Selkowitz
2020-05-26  4:31               ` Marco Atzeri
2020-06-08 19:20                 ` Jon Turney
2020-06-08 20:02                   ` Marco Atzeri
2020-06-09 13:20                     ` Jon Turney
2020-06-09 19:16                       ` Marco Atzeri
2020-06-12 14:44                         ` Jon Turney
2020-05-25  5:02       ` Marco Atzeri
2020-07-07 18:40         ` Marco Atzeri
2020-07-09 23:52           ` airplanemath
2020-07-10  5:34             ` Marco Atzeri
2020-04-04  3:17 ` Putting packages up for adoption Marco Atzeri

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eaa84baf9bad787ab6f1c2078c77dcd383f38597.camel@cygwin.com \
    --to=yselkowitz@cygwin.com \
    --cc=cygwin-apps@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).