libnewt0-shlibs update to version 0.52.25

[sth0]

removed python libs since did not want explicit python version dependency for various OS versions
Now builds on macOS 15
set new source download
alphabetized depends
removed dependence on debian utilities and docs
There are a lot of commented lines that may be obsolete on this update. Should remove those lines before merging
See Issue #1243

[TheSin-]

All my packed I keep in line with Debian as I use fink for testing Debian things. So I’ll have to make verianta much to my dismay

[sth0]

Ok, I can go back to the drawing board and try to base the source off the Debian package. There were a lot of Debian patches in the older source (2016) which I had hoped had been taken care of in the newer release.

The original conversation was about the package needing python 2.7 and 3.5 which is not available for macOS 15.
Does there need to be a split off for each version of python and can each split off have a distribution limitation? Or does there need to be a series of distributions each macOS with a possible split off for the various python versions available for that OS? I am not sure which is the "fink way" of handling this.

[nieder]

Debian has a single python variant (py313). We don't need to have umpteenth variants. I would say just py310 and be done with it. Add Conflicts/Replaces on the py310 variant with the older py27 and py35 to upgrade anyone updating the package from the old %v.

Here's the list of patches in current debian: https://salsa.debian.org/mckinstry/newt/-/tree/debian/master/debian/patches?ref_type=heads
And this is the debian tarball for Source2: http://deb.debian.org/debian/pool/main/n/newt/newt_0.52.25-1.debian.tar.xz

Does the package really need automake-1.16 ? I don't see changes to Makefile.am

[TheSin-]

I'd say 3.11 at least since that's buster default, going further back seems odd.

[sth0]

Of course linking only to libs for python 3.11 will break earlier macOS that can't use that? In fact I don't see a python3.11 package at all.

[TheSin-]

oh you are right I have 3.10, no wonder stuff is wonky for me with python dev :D. Guess 3.10 it is 🤮

Man I keep using my wrong account :\

[dmacks]

Ok, I can go back to the drawing board and try to base the source off the Debian package. There were a lot of Debian patches in the older source (2016) which I had hoped had been taken care of in the newer release.

The original conversation was about the package needing python 2.7 and 3.5 which is not available for macOS 15. Does there need to be a split off for each version of python and can each split off have a distribution limitation? Or does there need to be a series of distributions each macOS with a possible split off for the various python versions available for that OS? I am not sure which is the "fink way" of handling this.

The usual way is to have one .info for the library itself (-shlibs and -dev, for example) and another .info for the python bindings (-py27, -py310, etc.). That latter one would have variants for whichever python version(s), and each variant can be restricted to only certain OSX versions if necessary (only one variant is built at any time, not multiple python-versions' bindings all at once and then spread into SplitOffs).

See for example libxml2.info (libxml2 and libxml2-shlibs built together) and libxml2-py.info (libxml2-py27 and -py310 any one of which is built selectively).

[nieder]

The usual way is to have one .info for the library itself (-shlibs and -dev, for example) and another .info for the python bindings (-py27, -py310, etc.).

This assumes that the bindings can be built independently of building the library. I can't remember what package, but there was some library that had to all be built at the same time (couldn't use compiled/installed library when making the bindings). I think the solution was to 1) have library in own .info, 2) in a separate .info (for all variants), build the library with bindings turned on for pythonX, build the binding, install everything, then delete all but the binding when making the .deb.

[sth0]

@dmacks , that seems like a possibility but the original was not constructed that way for some reason. It is not clear to me that the bindings for python 3.5 and python 2.7 were included in the build as SplitOffs because they had to be built at the same time? It builds libnewt0-shlibs and then also newt-py35 and newt-py27 debs. This may be the issue @nieder suggested. I am not sure of the "fink way" of dealing with this.

I fundamentally don't understand what those split offs are doing. For example SplitOff3 lists as one of the "Files:" lib/python2.7. Does that mean that SplitOff is install a whole modified library for that version of python. Here is the Splitoff for python 2.7. It installs some examples and "peanuts.py" and "popcorn.py" which don't seem to be versioned.

SplitOff3: <<
       Package: newt-py27
       Depends: <<
               %N (= %v-%r),
               slang2-shlibs,
               python27
       <<
       InstallScript: << 
# examples
install -d -m0755 %i/share/doc/%n/examples
install -m0755 peanuts.py %i/share/doc/%n/examples/
install -m0755 popcorn.py %i/share/doc/%n/examples/
       <<
       Files: <<
               lib/python2.7
       <<
       DocFiles: CHANGES debian/copyright
       Description: NEWT module for Python
       DescDetail: <<
This module allows you to built a text UI for your Python scripts
using newt.
       <<
<<