? about gjots2

General talk about packaging procedures and packages.
User avatar
gapan
Salix Wizard
Posts: 5607
Joined: 6. Jun 2009, 17:40

Re: ? about gjots2

Post by gapan » 25. Mar 2020, 21:46

Well, it's everything that depends on python3. That includes all packages that have "python3" or "py3" somewhere in their name, but it's not limited to those. And then all packages that depend on those packages. And so on... Sorry, it would be too time consuming to try to track all of them.
Image
Image

salix_user
Posts: 43
Joined: 23. Jan 2019, 13:15

Re: ? about gjots2

Post by salix_user » 26. Mar 2020, 06:52

gapan wrote:
25. Mar 2020, 19:50
It depends. There is a /usr/bin/python3 symlink that will point to either python3.5 or python3.7. If something depends on python 3.5 and the symlink points to python3.7, and it is launched with /usr/bin/python3, then it won't work. The opposite won't work either.
Probably, creating a specific /usr/bin/python3.5 symlink, that points all salix's pkgs that depend on python3.5 to python3.5, could be solve the problem of having multiple versions (e.g. 2.7 3.5 3.7) of python in the system ? Is it possible in salix14.2 ? Is it possible in salix15 ?

User avatar
gapan
Salix Wizard
Posts: 5607
Joined: 6. Jun 2009, 17:40

Re: ? about gjots2

Post by gapan » 26. Mar 2020, 07:48

That symlink already exists. But then you have to edit every python 3.5 script in your system. I'll also state once again that the main concern is not python itself, but everything else that depends on it, starting from python libraries which are also version specific.

There is no way around it. The only way to "fix" this is to build all python3 related packages for 3.7, changing the names to be specific to 3.7, and then install those packages along side the existing ones. I'll let you do that. Come back to me in a couple of weeks when you're finished and I'll point you to all remaining broken packages.

And this is not specific to Salix. You have the exact same thing (I won't call it a problem) in any distribution that ships some version of python3. If you upgrade your python, you have to rebuild everything that depends on it.
Image
Image

DidierSpaier
Posts: 331
Joined: 20. Jun 2016, 20:15

Re: ? about gjots2

Post by DidierSpaier » 26. Mar 2020, 18:30

As an aside, I will do this mass rebuild for Slint only when I will be sure which version will be shipped in Slackware 15 (currently 3.8.2), to avoid having to to do it twice :D

salix_user
Posts: 43
Joined: 23. Jan 2019, 13:15

Re: ? about gjots2

Post by salix_user » 26. Mar 2020, 20:29

DidierSpaier wrote:
26. Mar 2020, 18:30
As an aside, I will do this mass rebuild for Slint only when I will be sure which version will be shipped in Slackware 15 (currently 3.8.2), to avoid having to to do it twice :D
For Slint 14.2 64-bit ? You will install the packages along side the existing ones ?
gapan wrote:
26. Mar 2020, 07:48
There is no way around it. ..
And this is not specific to Salix. You have the exact same thing (I won't call it a problem) in any distribution that ships some version of python3. If you upgrade your python, you have to rebuild everything that depends on it.
/usr/local /opt ?
https://hackersandslackers.com/multiple-versions-python-ubuntu/
https://github.com/pyenv/pyenv
?

DidierSpaier
Posts: 331
Joined: 20. Jun 2016, 20:15

Re: ? about gjots2

Post by DidierSpaier » 26. Mar 2020, 21:13

salix_user wrote:
26. Mar 2020, 20:29
DidierSpaier wrote:
26. Mar 2020, 18:30
As an aside, I will do this mass rebuild for Slint only when I will be sure which version will be shipped in Slackware 15 (currently 3.8.2), to avoid having to to do it twice :D
For Slint 14.2 64-bit ? You will install the packages along side the existing ones ?
No. The packages built against Python 3.5.9 and as many as possible built against 2.7.17 will be rebuilt against python 3.8.x and the new packages will replace the previous ones.

User avatar
gapan
Salix Wizard
Posts: 5607
Joined: 6. Jun 2009, 17:40

Re: ? about gjots2

Post by gapan » 27. Mar 2020, 21:21

I don't think you're listening. I repeat: There is no way around it.

The first link can be considered an ugly hack. The second is a way to create a python development environment. There is no way that could make hundreds of python libraries present in a distribution magically work for another version. You'd think all those distributions out there would have found a way to do it by now if there was one.

Feel free to waste^h^h^h^h^h productively spend your time actually trying to find a solution to this.
Image
Image

User avatar
mimosa
Salix Warrior
Posts: 3141
Joined: 25. May 2010, 17:02
Contact:

Re: ? about gjots2

Post by mimosa » 28. Mar 2020, 07:31

I would add, even if it worked, it would be a sledgehammer to crack a nut. The whole point of a Linux distribution is that it embodies a series of choices between different ways things could have been done. Your starting point should be to use what's provided (in this case, zim). A distribution's repositories are its horizon. If you go over the horizon, you are in uncharted waters. You can have a lot of fun tinkering and probably learn a lot in the process, but you can expect to break things (that's where the learning comes in).

I'm sorry that I may have set this hare running by suggesting (in another topic) that you install a more recent version of Qt5 from Eric's repository. The advice you were given from laprjns there was more sound. There are exceptions, but they would generally be applications, that don't have anything else that depends on them - such as vlc.

My positive suggestion is to put a test installation on a spare partition. You could even run Slackware current there. Throw everything at it, and when it gets too messy, just wipe it and start again.

There is also our sister distribution Slackel, based on current:
http://www.slackel.gr/forum/about.htm

Post Reply