Exactly that's WHY I imagined the files storage solution for that information.

Let's do not exaggerate. It is wrong to make a bit of order and classification?

Eh?

How did you work that out from what I said?

As has been pointed out previously by others, edit the tagfiles yourself, the mechanism is there

The mechanism is not there, sorry...

Because the tag files are a way to present a "view" of packages to be installed. BUT, they does not offer a categorization of the packages. Again, think about the package sets, not the tag files.

I for one, I would love to be written in the packages database which ones are "KDE dependencies" specially, but also which ones are for "LAMP", which one are for "Mail server" and so on. Because I like a bit of order.

And I presented a simple way to add this information: those "install/slack-groups" files. Attention! I talk about the way simplicity, not about the required workload.

Could be done also via folders and links, but will be more complicated, at least on my humble opinion.

Of course, which information will be added in the end, I cannot decide myself for Slackware.

Because it's impossible to do what you want without knowing what programs rely on what. Someone earlier in this thread already mentioned an example of what could break by removing qt. wpa_gui, which is part of the wpa_supplicant package would no longer function as it relies on qt. Right now, it's obviously linked to qt4, but if qt5 were to replace qt4 in the next Slackware version, it is highly likely that wpa_gui would no longer function if qt5 were removed. That's one example of something that isn't even related to KDE that would be broken by your proposal.

Ok, that's all fine and dandy, but how do you know what goes in kdelibs and isn't used by any other programs in the distro? You can get a rough guess on what it is based on what's in ktown that isn't in -current, but that isn't all inclusive. How do you go about the current files in l/ and know that package a is only used by KDE and package b is used by KDE and XFCE? You don't unless you wrote down everything and do an ldd on the files to make sure they didn't link to anything you weren't intending. Maybe XFCE picked up some library you thought was only for KDE because it was an autodetected option in the ./configure. Now, when you remove "kdelibs" it breaks XFCE.

My proposal to you would be to find what packages only belong to KDE and provide that to the community. Then, as I mentioned before, you could take those packages and add them to your slackpkg blacklist file, then simply run slackpkg clean-system directly after (I realized this wouldn't work to remove them, but it could be used to ensure they don't get reinstalled) save them as a file then simply run removepkg `cat kde-packages-list.txt` and wait for removepkg to remove everything. I just tested this on 14.2 and it works fine (I removed 4 custom built packages that I no longer needed, and I had each on its own line).

This is able to be done without Pat modifying pkgtools and all the package information on all the mirrors. This feature is already included.

With something like this, if enough people were interested, the community could create a website with various lists of packages and could even create an automated tool like sbopkg to make it so you don't even need to download a file or copy/save the list from a page (maybe something like slackcat remove kde and it could be used in the opposite manner of slackcat add mplayer which could add ffmpeg and all the other associated packages that someone added to a list). I personally have no desire for this because I do a full install out of laziness and to ensure packages from SBo have all required packages.

Pat already stated in a previous thread that package sets don't really mean anything specific and that people shouldn't look too far into them.

I don't mean that anything that is a benefit to you shouldn't be included, but unless dependencies are brought in (as mentioned above), it'd be hard to find what programs rely on them to ensure you're not removing something important, so the only semi-easily added category would be kde and/or qt. Everything else would be a lot more work, and if we were talking about KDE4, it still be a lot of work to find what packages in l/ are only used by kde and not anything else.

The existing groups are already good enough. In this hypothetical world where Plasma 5 is in Slackware, just remove the KDE group and move on. What's the big deal with having a couple unused libraries hanging around? I don't get it.

The Plasma5 dependencies conflicts with ones of KDE4.

If someone wants to install back the KDE4, after it is replaced in -current by Plasma5, he should do a big cleanup.

I look into https://alien.slackbook.org/ktown/cu...5/x86_64/deps/

Probably the suspects to arrive into L set. Well, they are many.

Could be better all those dozens of packages to be installed by Slackware in their own packages set?

I know, I know, I already proposed that...

Usually, if one wishes to replace a major desktop environment from a distribution with a different version, he should expect to do a little bit of cleanup. I don't see why you think Patrick should be obliged to do that work for you. Plus, no one is forcing you to upgrade to whichever version of Slackware eventually includes Plasma 5.

1 members found this post helpful.

For some (unlucky?) hardware combinations as reasons, I am already either stuck in 14.1 or -current. You suggest me to skip also the v15 ?

And I do not think that P.V. is obliged to do that work for me. I will do myself this work.

What I hope is him to label the packages added in the near future: "this one is for Plasma"

Trusty Tahr

If nothing else works, try to find this guy.

Well, this "disturbance in the Force" made me think that we underuse the installer and slackpkg.

There are two scripts in every package set: maketag (for expert mode) and maketag.ez (for the easy menu mode).
We can make maketag (expert mode) select a small set of packages by default. Just enough to have a working slackpkg (and network access will be good too). So after a minimal "expert" install one can configure slackpkg with templates and blacklists and install the kind of system s/he wants. For example we can put a NO_Plasma5 blacklist in /etc/slackpkg and after a minimal install run "slackpkg install slackware64".

I am ready to help with the minimal package selection and the testing.



Cheers

4 members found this post helpful.

@ivandi

Thanks you for the help offer, when the time will come, permit me to contact you.

In a public way, as I believe that the ability to install Slackware without Plasma, in the future, as of general interest, i.e. for XFCE-only users.

It's already possible to not install KDE. Maybe some unused libs will stay in the system, but why bother?

Could you guys start with KDE4?

I am pretty sure that I do not want KDE4, it is too bloat to work in computer, too basic specs for it.

How I do not want KDE, and I am convinced that I do not want it, its leftovers became just PUPs, after all books.

https://en.wikipedia.org/wiki/Potent...wanted_program

Because I do not want KDE and those "unused libs", and the operating system should respect my decision, because I am its owner?

See my previous post for the definition of PUPs and to note that Ubuntu or Fedora does not force me to install KDE or bits of it.