I think it will be quite fast.
I could write a shell script automatically identifying packages with python2
and python3 packages and adding standard python3 handling in the base
SlackBuild, in one hour or two.
Then we'll have to test them all, but obviously we'll have to test most
SlackBuilds at that time.
But as I remember the window is not too small, as it starts with first RC, and
Pat is never in any rush to ship a new version.
Le February 21, 2019 10:20:04 AM UTC, David Demelier <[email protected]> a
écrit :
>Le 21/02/2019 à 01:32, Daniel Prosser a écrit :
>> I like the idea of having a single script for both Python 2 and
>Python 3
>> versions of each module (or as many as possible), but I don't think a
>
>> lot of work should be done to enforce uniformity for 14.2. When
>> Slackware 15 comes out, Python 3 will be included and the issue of
>> dependencies will be moot for most scripts. For now, I can deal with
>> maintainers taking different approaches.
>
>Won't it require lot of a time to do the merge for 15.0? I mean, how
>long are freeze times before a new Slackware version?
>
>That's why I thought the master git branch was used to track
>slackware-current. Now I feel like once we have a code freeze in
>Slackware, we need to do as quick as possible the modifications in
>master to match the new upcoming release.
>
>Or perhaps I understood something wrong.
>
>--
>Regards
>
>_______________________________________________
>SlackBuilds-users mailing list
>[email protected]
>https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>FAQ - https://slackbuilds.org/faq/
--
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma
brièveté.
_______________________________________________
SlackBuilds-users mailing list
[email protected]
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/
