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.
Whilst this may fix the specific issue in Slackware, I feel it is still important to patch solid as well. The developer has acknowledged that there is a bug in solid:
There may be other - as yet undiscovered - situations which trigger this crash, so hopefully the patch for solid will also be incorporated into Slackware soon.
In other words, the rc.S patch fixes the specific, the solid patch fixes the generic.
--
Pete
I know the issue very well , im the 1st on report here and point to solid , but we know solid 5.85 arrives fixed and slackware make a better directory organization , then WE HAVE DOUBLE FIX.
Because now we have solid-5.84 thats the version we need fix , and for now its at least usable.
Whilst this may fix the specific issue in Slackware, I feel it is still important to patch solid as well. The developer has acknowledged that there is a bug in solid:
There may be other - as yet undiscovered - situations which trigger this crash, so hopefully the patch for solid will also be incorporated into Slackware soon.
In other words, the rc.S patch fixes the specific, the solid patch fixes the generic.
Plasma 5.85 is expected to be released on 14 AUG. So if Pat doesn't decide to add the Solid patch, the updated version should make it to Slackware in around 2.5-3 weeks if Pat sticks to upgrading it within a few days of release.
If you have to update the entire stack (frameworks or plasma, etc), why split kdelibs into separate packages? It just doesn't make sense to me that if the entire thing needs to be updated why have 10000 packages to update instead of just one?
All of them get version bumped at the same time so it's not like there is more actual work going on to any lib that doesn't get any code changes so it turns out to be more actual work and more files to deal with.
If you have to update the entire stack (frameworks or plasma, etc), why split kdelibs into separate packages? It just doesn't make sense to me that if the entire thing needs to be updated why have 10000 packages to update instead of just one?
All of them get version bumped at the same time so it's not like there is more actual work going on to any lib that doesn't get any code changes so it turns out to be more actual work and more files to deal with.
Probably because all major distributions excluding Slackware uses dependencies resolution and usually they do not install everything like us.
They install just what they need for a particular feature.
Probably because all major distributions excluding Slackware uses dependencies resolution and usually they do not install everything like us.
They install just what they need for a particular feature.
I suppose that makes sense.
However, I don't install KDE but I do install KPatience and it went from installing 3 packages (kpat, kdelibs and libkdegames) to 30 packages. Where is the difference? I don't think that you can install too many programs/applications from KDE without needing at least most of what was in kdelibs.
However, I don't install KDE but I do install KPatience and it went from installing 3 packages (kpat, kdelibs and libkdegames) to 30 packages. Where is the difference? I don't think that you can install too many programs/applications from KDE without needing at least most of what was in kdelibs.
KDE devs decided to split it up to allow non-KDE software to use specific components of what would've been in kdelibs without needing to introduce a dependency on the whole thing.
When you try and install KDE software without installing all of Plasma5, it will bring in a lot of packages as you've seen, but if someone only wants to use khtml (I don't know why they would, but, it's my example), the required list could potentially be a lot smaller.
My guess is that KDE devs figured the requirement of including kdelibs was high enough that many people wouldn't develop using their libraries unless they knew it was basically a KDE app. This gives outside devs more flexibility to allow them to use some functionality of KDE without bringing in the whole kitchen sink.
However, I don't install KDE but I do install KPatience and it went from installing 3 packages (kpat, kdelibs and libkdegames) to 30 packages. Where is the difference? I don't think that you can install too many programs/applications from KDE without needing at least most of what was in kdelibs.
I don't believe that you need all of the 30 packages just to satisfy kpat's dependencies.
For example, a Kubuntu 20.04 shows these dependencies for kpat:
KDE devs decided to split it up to allow non-KDE software to use specific components of what would've been in kdelibs without needing to introduce a dependency on the whole thing.
When you try and install KDE software without installing all of Plasma5, it will bring in a lot of packages as you've seen, but if someone only wants to use khtml (I don't know why they would, but, it's my example), the required list could potentially be a lot smaller.
My guess is that KDE devs figured the requirement of including kdelibs was high enough that many people wouldn't develop using their libraries unless they knew it was basically a KDE app. This gives outside devs more flexibility to allow them to use some functionality of KDE without bringing in the whole kitchen sink.
Yes, IIRC the size of kdelibs and co. was the number one complain for not using them in external projects, which derived in the current split and tiers of KF5, but to make the lives of distro packagers a bit easier they still release them as a whole.
I'm not really complaining or anything, I can figure it out as I did. I'm just trying to figure out why they split kdelibs. I don't know too many projects that use KDE libraries. I know that LXQt does, but with the new and improved Qt license who would want to develop on KDE/Qt. Don't get me wrong, GTK is a mess as well now with CSD so the whole system looks like a cobbled together mess.
I don't know too many projects that use KDE libraries.
This is probably a big reason they decided to split it. People weren't using KDE libraries because the footprint was too big when they had to require all of kdelibs.
It is likely their hope that more people will start using KDE libraries now that they're much smaller and may not pull in nearly as many dependencies.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.