On Thu, Sep 29, 2022 at 2:25 PM Marcel Telka <mar...@telka.sk> wrote:
> Hi, > > Currently we provide Python versions 2.7, 3.5, 3.7, and 3.9 for > OpenIndiana, while version 3.9 is the default version. > > Both Python 2.7 and 3.5 are no longer supported for two or almost three > years now respectively - see > https://devguide.python.org/versions/#versions for details, so we > started to obsolete them. Since there are many related packages that > needs to be rebuilt to get python 2.7 and 3.5 obsoleted, this transition > is expected to take long time (probably weeks, maybe months). > > There are basically two sets of related packages: > > #1 software that uses python (e.g. gimp), and > #2 packages that provide some enhancement to python; these are usually > python modules, for example cherrypy. > > For #1 we just need to rebuild packages that require python 2.7 or 3.5 > so they start to require either python 3.7, or python 3.9. Volunteers > are welcome! > > For #2 the situation is a bit more complex. The name of all packages in > this set is starting with 'library/python'. There is usually a basic > package (e.g. library/python/cherrypy) and few version specific packages > (e.g. library/python/cherrypy-35, library/python/cherrypy-37, > library/python/cherrypy-39). Another example is library/python/pycups > and its library/python/pycups-27 and library/python/pycups-35. > > For such packages we will slowly obsolete their -27 and -35 variants. > In a case there is neither -37 nor -39 variant already available, nor it > is needed for some other package, we will end up with all package > variants obsoleted. If this happens, then in addition to obsolete of > both -27 and -35 we will obsolete the base package too. > > For example, cherrypy. There are already -35, -37, and -39 variants. > We will obsolete the -35 variant and both -37 and -39 will be kept, so > we will keep the basic library/python/cherrypy too. > > When looking at pycups, we will obsolete both -27 and -35 variants. > Let's assume there is currently no other package that needs pycups, so > we would end with orphaned library/python/pycups, so we will obsolete > the library/python/pycups package too. > > Based on the rule above we already obsoleted following packages > recently: > > library/python/augeas > library/python/backports.shutil_get_terminal_size > library/python/backports.tempfile > library/python/cheetah > library/python/click > library/python/cssutils > library/python/cython > library/python/dulwich > library/python/geoip > library/python/elixir > library/python/import-profiler > library/python/kafka-python > library/python/livereload > library/python/m2crypto > library/python/mkdocs-bootstrap > library/python/mkdocs-bootswatch > library/python/mkdocs > library/python/netaddr > library/python/netifaces > library/python/numpy > library/python/pygtksourceview > library/python/pymongo > library/python/pyorbit > library/python/pyrex > library/python/pyro > library/python/python-ldap > library/python/python-memcached > library/python/python-mysql > library/python/python-notify > library/python/python-sexy > library/python/pywbem > library/python/scientific-py > library/python/sqlalchemy > library/python/typing > library/python/unittest2 > > Here is a list of packages that could get possibly obsoleted soon: > > library/python/backport_abc > library/python/backports.functools_lru_cache > library/python/backports.ssl_match_hostname > library/python/colorama > library/python/decorator > library/python/enum > library/python/flamegraph > library/python/funcsigs > library/python/ipaddress > library/python/ipython > library/python/ipython_genutils > library/python/notify2 > library/python/pickleshare > library/python/prompt-toolkit > library/python/pyatspi2 > library/python/pycups > library/python/pygobject > library/python/pygtk2 > library/python/python-compizconfig > library/python/python-xdg > library/python/python-xlib > library/python/rbtools > library/python/simplegeneric > library/python/traitlets > > If you need any package from these lists then please create a pull > request (see https://github.com/OpenIndiana/oi-userland/pulls) to get > the package back and built for python 3.7 and/or 3.9 (in a case it is on > the first list of already obsoleted packages), or either let us know or > create a pull request to rebuild the package for python 3.7 and/or 3.9 > (if it is on the second list of packages we could possibly obsolete). > > Any help with this task is very welcome (for example pull requests to > get software in set #1 rebuilt). > > Please note that support for building python modules for python 2.7 and > 3.5 was already dropped from oi-userland. > I do not understand the need for obsoleting the entire package and removing all the files instead of updating on the go. Could you explain the motivation? To me this seems a bit of overhead, like removing the mkdocs, cython, numpy packages completely from the tree instead of updating them. We therefore lose track of what was in the tree and people may start from scratch all over again. Maybe you intend to provide some level of automation later? An earlier heads-up before starting to remove everything could have been nice to have a chance to update a few components in advance and avoid the mumbo-jumbo. Thank you > > > Thank you. > > -- > +-------------------------------------------+ > | Marcel Telka e-mail: mar...@telka.sk | > | homepage: http://telka.sk/ | > +-------------------------------------------+ > > _______________________________________________ > oi-dev mailing list > oi-...@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev > -- --- Praise the Caffeine embeddings _______________________________________________ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
