Adam <adam%netbsd.org@localhost> writes: >> textproc/py-cjson - only for Python 2.7; no dependencies >> >> www/py-cherrypy17 - Python 2.7 version of www/py-cherrypy > > Since Python 2.7 has become obsolete, it is more and more difficult to > maintain Python packages. Packages are dropping 2.7 support > quickly. Many Python updates in PkgSrc are blocked by this fact. IMHO > we should move toward dropping Python 2.7 as well. Providing older > version just for keeping Python 2.7 compatibility creates a dependency > nightmare. > > I say, we should get rid of some old and unmaintained Python packages to clean the mess. Surely there are a wide wariety of opinions within the pkgsrc community, and I don't think either "keep everything 2.7" or "nuke 2.7 stuff now" is really apppropriate. It's going to be a case-by-case decision -- which is the path Adam is entirely reasonably heading down. But, I think the decision needs to be framed in terms of balancing the interests of pkgsrc users with the willingness of pkgsrc contributors to maintain things. This means a few things that are often missing from the discussion: "no dependencies in pkgsrc" is not the whole question for whether something is unused. People use pkgsrc to provide software to be used other than by other packages. "maintenance effort" is a question that can be viewed from different angles. Simply deleting something as part of a "let's get rid of all 2.7 things" doesn't really reduce effort -- the reduction of need effort comes from saying "it's ok if this stops working", and the reduction of applied effort comes from people just deciding not to fix things. Therefore, the real question is when a packge's presence in pkgsrc causes people not to do otherwise reasonable things that they would like to do, and have to do extra work to work around it, and trading that off with utililty to users. Typically a python library used to support 2.7 and 3.x and has a new release that is only 3.x. If everything that used the library was already converted to 3.x and had a **formal release**, that would be fine, but many projects aren't really maintained. So in pkgsrc we (and Adam in many cases) have added older versions of libs that do 27, and arranged to use them for 2.7, but use the newer (maintained!) version for 3.x. In the case of py-cherrypy17, I don't even know what it does, but in my view the real work is setting up the old version, and I don't see what reduction in work deleting it gets us, as opposed to just leaving it and not really caring if it builds. So I'd like us to be on the slow side to remove the 27 version of split old/new packages. There, I think the argument to remove should be "I don't believe that anybody is actually using this for any reason." For packages that would normally be updated to a 3.x version from a 2.7/3.x version, there the question is whether a 2.7 version needs to be added or not, and that's where I see the harder questions.
Attachment:
signature.asc
Description: PGP signature