The primary problem that @DarthVader is attempting to solve is a way for him/her/it to remove some subset of packages without any work on his/her/its part. In particular, remove all KDE5 related packages so that he/she/it can re-install KDE4 to run a program that is used by his/her/its company.

So, asking how exactly these hand-waving-just-tags strings do not stumble across and trip upon dependencies and package removals are entirely on point.

I assume that @DarthVader will be building a new set of KDE4 libraries and binaries against the Slackware 15.0 (assuming that's when KDE5 shows up) code base, but that's another tale.

I think that the story about KDE4 vs. Plasma5 made me aware about something which I consider a need and room for an improvement. A better/more generic categorization of the packages, as in better/more generic than the one given by packages sets.

Would be it adopted by Slackware? I do not think so, considering the position of our BDFL. From this POV, is just a theoretical discussion.

But maybe would be useful for someone, if it is explained clear. Because you can organize well the packages also without automated dependencies tracking.

And I do not do this discourse only and only driven by "my interest". At the end of day, that particular software was designed for CentOS 7, and so I will use it.

Sure, I will love to use Slackware instead, but it is not a must be. In fact, is more like a fan preference.

Of course that I would have to build my own version of KDE4 for a particular version, if it will be replaced with another things.

PS. I am an "him".

I sense a certain amount of indignation that someone should have to know about (and declare) the dependencies of a package or group of packages.

I don't believe that the indignation is warranted. For that big group of packages known as "Slackware", Patrick & team figure out all the dependencies so that we mere mortals don't have to dirty our hands with such stuff. If we start having groups of packages that are "complete" with respect to dependencies, then their respective authors would indeed have to figure out the dependencies - exactly as for the "Slackware" meta group. Why worry if the mechanism for determining package groups are just about the same as for producing Slackware itself.

I guess there would be an issue around who creates and maintains these package group definitions. If Patrick & team did that, then we could have reasonable confidence (based on past experience of Slackware itself) that the package groups are accurate, work as expected etc. However that implies additional work for the team, even if they already know the dependencies of all the Slackware packages. Allowing anyone to define package groups has obvious shortcomings - would you trust X's definitions or not? Well that's up to all of us as individuals whether we trust X or not. However I do trust myself, so a mechanism to support package group definitions would be useful for at least groups I might define myself.

So, it would be nice if the mechanism itself existed. It wouldn't be compulsory; if it smacks too much of a slippery slope into dependency hell, then don't use it.

Who writes the code to add such support? If there were any indication that contribution of code for such support would be welcome, I reckon there would be volunteers to work on it.

chris

2 members found this post helpful.

The example code patch for the installpkg I can write it myself. It is something like was shown by @LuckyCyborg, who looks like already understand the concept.

And in fact, this is the single change, supposed by my concept. Which has only an informational side.

No other changes I supposed to be. How this concept is developed further, depends by the need of those who use this concept.

I think the changes in installpkg are small.

There is just a need for read this "slack-groups" file, merge the lines and put the data in package file. I hope this is it, if I understand right.

Yep, this is idea, and the changes needed to register the groups information.

In fact, that's all what this thing do: (optionally) registering the content of that "install/slack-groups" file, where are a set of labels, one per line.

No more than tomorrow I will post this patch here, for discussions.

@DarthVader has provided a particular use case that we can all pass judgement on regarding whether it's a good or bad thing to do.

Whether the individual case has merit or not shouldn't distract us from the more general desire of anyone to remove some subset of packages without any work on their part. I seem to see requests on LQ nearly every day about how to safely remove some package(s) or other, the general advice in response being to keep the full set of packages. Nevertheless there is clearly a desire in a not inconsiderable portion of the user base for such a mechanism.

chris

2 members found this post helpful.

And there has been considerable feedback from the maintainers that they aren't interested in supporting such a thing beyond (if even that) the installer.

At which time, I'd expect the "not inconsiderable portion of the user base" to come up with something to scratch that itch other than "let's bug the maintainers to do it for us!" There have been a couple of suggestions in this thread by others that could provide such a thing with the tools that are in place right now.

Nobody knows what you are on the internet.

I am an "him" as well.

I didn't mean to imply the dependencies of a "set" would be required to be disclosed, but they would need to be determined to find out if removing that "set" would cause other issues in Slackware. I always imagined the "set" would just be packages they didn't want after determining they won't break Slackware by removing them, and I think this is what Darth has in mind as well (at least the first part... I'm not sure if he cares about the collateral damage that can occur by excising some of these packages). I also think that if Pat and team were to be the ones implementing this, that they'd have a pretty good idea of what depends on what. After all, they rebuild a lot of programs due to .so bumps of various libraries. But they've also made it clear that they don't intend to support this on their end, which would leave this to be a community effort.

I already provided examples in my last post (based on posts by others in this thread) with qt being required for wpa_gui and xpdf, neither of which are associated with KDE. Yet Darth would lump qt5 in with KDE5 and would want it gutted, no matter the consequence on these other programs (at least, he hasn't responded what his intentions for these programs would be). For him, this is likely not a big deal, because he'd know that if he wanted wpa_gui or xpdf that they'd likely just need a recompiling to link to the qt4 he has in his system, but should others already know that? Should there be a README of potentially broken programs with each "set"? Should certain "sets" automatically invoke the removal of other "sets" (if there were a qt "set", should it automatically remove the kde "set"?). I also provided examples of several image libraries that are tied to a video program that would be broken if they're removed, but if someone wanted to remove all image related PUP, should that include libjpeg-turbo, libpng, etc since they are image related, even if it means ffmpeg and other programs would stop functioning?

By no means am I against slimming down Slackware... when it's done for the right reasons (even if I have no intention on slimming my install). Plenty of people have legitimate reasons (including just the learning aspect of slimming a system). I even totally understand and support Darth's reasoning for not wanting KDE5 and sticking with KDE4. Sometimes legacy software requires us to make changes from the easy route. I have no issues with these "sets" being created and maintained by the community, and I even offered a perfectly reasonable and working solution on how to easily implement them with the existing tools in Slackware, without requiring modification to those tools.

But he keeps saying dependencies are not needed for this project, which is absurd, unless you don't care if things get broken. There are good resources out there that can be utilized to determine what requires what without reinventing the wheel, but some sort of dependency checking should be used while creating the "set" to ensure you're not going to end up with a broken Slackware the next time you reboot. Sometimes the only dependency checker needed is your head (for simple enough libraries that you know are tied to only a handful of programs), but that is still determining what your software relies on and whether it is safe for removal.

3 members found this post helpful.

This ↑, so many times this.

2 members found this post helpful.

This thread is going round in circles, which usually leads to nowhere.

We know that Patrick will not change anything in PKGTOOLS or any other part of Slackware, at least unless and until someone proposes something proved useful, with no ill effects and with very few additional maintenance needed. As a comparison let's remember that it took years, not weeks or months, to accept in Slackware slackpkg, developed mainly by Peter Punk.

So here is a proposed road map for any idea not to remain just that forever:

1. Write down a a draft specification. As of now the why and what are still unclear to me, let alone the how.
2. Make it the topic of a RFQ.
3. Make a prototype.
4. Have it assessed.
5. Implement that as a third party tool.
6. Use and maintain it it for some years.
7. Optionally, request its inclusion in Slackware.

Of course all this has to be done by volunteers.

Good luck, and have a nice day.

5 members found this post helpful.

In view of the current groupings of packages (a/ap/d/e/f/k/kde/kdei/l/n/t/tcl/x/xap/xfce/y) there is already a considerable division in 'groups' that works: On my box nothing from e, kde, kdei is installed and one big l-library that is kde-related (akonadi) is left out as well. Some of the lost functionality (like the calculator, su-login for x etc) is replaced by packages picked from SlackBuilds.org, but essentially everything works fine and I have tons of other stuff on top that that compile/work OK.

But, both Qt5 and Qt4 are on my box; many programs (not coming from Kde.org) need either of them to present themselves. So another suggestion could be to move any kde/tcl/t/etc-ONLY library to the kde/tcl/t/etc 'floppie'-folders to make this functional division more obvious. Anything, like Qt, that is/will be used by other providers of software should remain in l; When/if Qt5 replaces Qt4, back-porting of Qt/Kde could be made possible via SlackBuilds.org and become part of a common routine to adapt the range of software on one's box.

Maby we should reconsider the definition of what is absolutely needed to run Slackware, 'A full install' is the obvious answer but maybe we could slim it down a bit to 'A full install with kde/xfce/.. optional')

If you look at past releases of my 'ktown' repository containing the Plasma5 desktop you will notice that I have been providing backwards-compatible KDE4 support for all those tarballs in the KDE Applications that had not yet bene ported to KDE Frameworks 5. When Slackware moves on to Plasma 5 and leaves KDE4 behind, you can use the source code in my repository to create packages for these packages you mention. I already have there:

kdelibs
kdepimlibs4

... and it will be trivial to add the rest. It could even be an option to keep those packages in my repoitory after Slackware adopts Plasma 5 and removes KDE 4.

I said multiple times that those "package groups" has no abilities to handle the dependency resolution, just like the today packages sets based on folders.

And that the handling of the dependency resolution is not between the objectives of this idea and it cannot help for. Again, my idea is all about categorizing/labeling the packages in a meaningful and generic way.

Then, I believe will be no changes in how the dependencies would be handled if this concept is adopted by someone: just like they are handled now by a Slackware (like) distribution: manually by some, with some helpers by others.