[Slackbuilds-users] Python (Again!)

Barry J. Grundy bgrundy at gmail.com
Wed Apr 21 00:20:35 UTC 2021


On 4/20/21 5:52 PM, Jeremy Hansen wrote:
> On Tue, Apr 20, 2021, 2:59 PM Barry J. Grundy <bgrundy at gmail.com 
> <mailto:bgrundy at gmail.com>> wrote:
>
>     I know this has come up before and perhaps been answered and I've
>     also
>     read through the related threads on LQ, but I still have not seen a
>     definitive answer (if there is one):
>
>     Since python2 is EOL and -current/15 ships with python3, is it good
>     practice now to build python packages with python3 by default?  If
>     so,
>     then what's the best way to handle the multiple versions? This
>     discussion was had on the list back in Feb of '19, but I don't see
>     anything definitive.
>
>     For example, I maintain dpkt.  The version in the -current (ponce's)
>     repo works, but I have an update ready to go when submissions open
>     again.  Right now dpkt builds for python2. Here's my question:
>
>     My "ready to go" update switches to python3 by default and uses a
>     "PYTHON2=yes" option to build python2 modules if the user wants.
>     Would
>     it be better to create python3-dpkt and leave the dpkt script at
>     python2?  I see it both ways in the 14.2 repo.
>
>     Another probably better example is distorm, which is a requirement
>     for
>     volatility (which is python2 only).  volatility3 is a separate
>     re-write
>     for python3 with different prerequisites (and I already have a
>     slackbuild to submit for that when things open again).  So for
>     volatility it makes sense to leave distorm as is.  I can submit a
>     separate python3-distorm script when I submit volatility3.
>
>     Perhaps with the submissions freeze it would be a good time to either
>     separate the scripts or at least decide on a "best practice".  My
>     apologies if I'm simply kicking a dead horse here.
>
>     Thanks,
>
>     Barry
>
>
> In my opinion, I think SBo for 15.0 should default to python3 for any 
> packages and python2 should be something that can be optional (for 
> those packages that support both).
>
> If there's a need to have separate python2 and python3 packages, the 
> python3 package should not need an identifier in front of it, where 
> the python2 package should ($PRGNAM for python3 and python2-$PRGNAM 
> for python2).

I agree with defaulting to python3 for 15.0.  But right now we'd have 
$PRGNAM changing to python2-$PRGNAM and python3-$PRGNAM changing to 
$PRGNAM.  Then when python4 comes out it would be a repeat of the same 
issue (maybe).  Perhaps "python$VER-$PRGNAM" would be appropriate for 
everything.

And perhaps I'm just over thinking it.  But thanks for the responses.

Barry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20210420/2e02a703/attachment.htm>


More information about the SlackBuilds-users mailing list