SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
So, does the advice to hold off on upgrading of you have Plasma 5 still stand? I don't like the idea of not updating for too long. Unexpected breakage can occur when the updates do happen.
If I get the feedback that my 'ktown' Plasma5 will (mostly) not break after applying the recent Python3.9 updates, then that is good news and I will upload all my DAW-related recompiled packages (like Cecilia, Guitarix, Muse, Mixx, Jamulus) which I have also been holding off until Patrick would finally add Plasma5.
I also fully upgraded my main desktop (64-current) with ktown through the Oct 31 updates, including Python 3.9. The recent, temporary, additions to aaa-elflibs seem to be doing the trick for now.
Last edited by Chuck56; 11-01-2020 at 11:13 AM.
Reason: added "with ktown"
Thanks, guys. Based on your advice, I updated yesterday, and so far I haven't noticed anything broken. I haven't tested everything, but at least I can confirm that it won't break your desktop.
Last edited by montagdude; 11-02-2020 at 08:40 AM.
Reason: accidentally wrote "anything" instead of "everything"
Same here. I updated all python related items this morning and so everything is running as it should. Had to reinstall glances and my protonvpn_cli but everything is a go.
Any thoughts on next steps to potentially fix KRFB? I'll give strace a try and see what else I can learn from that. I'm hoping it might be something simple but suspect it may require a rebuild of KDE5 or wait for the official KDE5 release.
Last edited by Chuck56; 11-02-2020 at 03:06 PM.
Reason: added strace comments
I understand the desire given a perfect world, but unless the installation is isolated to a small number of high-level application of interest to be tracked, it soon degrades into a dependency hell because different packages have different version requirements. Some applications are constantly being developed and require the packages to be up to date, and others are lagging and require older versions to be present. It quickly becomes impossible to satisfy both ends. This has been my personal experience, but it highly depends on what exact packages one is interested in maintaining. And as you rightly point out, there are the other packages for perl (cpanm), ruby (gem), etc. People already have to manage these themselves depending on what they are interested in supporting.
I'm a little behind, but simply put, most users don't care what versions they're running as long as the program works. All programs on SBo have been tested to work against the dependencies available on SBo, so we shouldn't run into version issues. That could mean for someone developing that they may not have the latest versions, but it's easy enough to run a local python version that is separate from the system version for that development.
There are many ways to handle software in a system and there are many ways to handle a software repo. SlackBuilds.org (SBo) has decided that all dependencies need to either be included with a full Slackware install or available on SBo. SBo also has a policy to not allow a SlackBuild to download software (it needs to be downloaded before the SlackBuild is run). This prevents maintainers from using pip commands in SlackBuilds. This also ensures that the Slackware package manager is aware of all packages installed on the system from SBo.
There is no perfect system. You can either stick with python packages as system packages via something like SBo, you can install via pip and keep the package management system unaware of python modules that are installed, or you can mix both of them. Each admin (usually you) makes the determination on what's best for their system. For me, I keep all my system python packages installed via SlackBuilds (either from SBo or self-generated ones--which I usually add to SBo), and I keep a local python folder with the latest python that I use for the occasional development I do (haven't done this in a few years as it was for a class). I don't like software installed on the system that pkgtool is not aware of.
All that being said, Duncan Roe decided to create a pip2tgz program that will allow you to install programs from pip using a wrapper script that will then convert them into Slackware packages. Maybe this will work for some people...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
