pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: To remove or not to remove



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



Home | Main Index | Thread Index | Old Index