Let me quote this:Of course that's a lot. So what? If that's actually what is needed (I didn't check as I never make a minimal installation) what's wrong in installing what's needed for the newly installed wpa_supplicant to work?

Anyway I didn't say that there is a problem with a full install. In Slint only a full install is proposed (just KDE is becoming optional). By the way in Salix the wpa GUI is not shipped in wpa_supplicant to avoid installing Qt just for that.

Now if you mean that the Slackware packaging way or method leads to added (or what one could call "artificial") dependencies, I agree. For instance it makes akonadi a dependency of a lot more packages than those that ship apps actually needing it.

But this makes Slackware very versatile out of the box, and splitting the packages as do other distributions would mean an amount of maintenance work that I assume Pat and contributors just can't handle.

The amount of maintenance work that Patrick Volkerding assume is connected also with his own preferences, to use those build scripts where he write every step of the process.

Slackware is not the only distribution using bash scripts to build packages. Look how the Arch do it - I get first package from the list.
What I want to say is: the Slackware maintainer works much much more for the same task, compared with other maintainers, because he prefer the "raw" scripts, where he control punctually everything.

No one can stop him to simplify his work, using a PKGBUILD like Arch, if he wants. It is also about preferences.

@ LuckyCyborg: I write SlackBuilds but also SLKBUILDs, mostly used by Salix to which I borrow the slkbuild application that process the SLKBUILDs, and very much doubt that makes a so big difference. Pat even writes the VERSION in such a way that it sets itself as the one in the source archive's name. The time spent in testing is certainly of an order of magnitude bigger than the one spent in editing the scripts, anyway.

I get what Darth is saying, and I sympathize, being a minimalist at heart, but after some reading and thinking, I've pretty much come around to the "install it all and use what I need" camp.

If I disabuse myself of the notion that package sets are intended in some way to make it easier to install subsets of Slack and instead treat them as a legacy from when Slack had to be divided up to fit on diskettes/CD's, then I get closer to understanding that I should be treating them like they don't even exist. Then, if I take that thought one step further, I'm almost forced to the conclusion that they shouldn't exist on the DVD at all, and the installer should just do an image dump of the whole shebang and call it a day.

IMO, their existence does send a kind of mixed message with regards to what's recommended/supported and what people (myself included) are trying to do with them. Trying to force package sets to be something they're not is only going to frustrate people on both sides of the "install it all" fence, and maybe consideration should be given to simply removing them.

Slack supports tagfiles, and maybe that should be the only way to go to install subsets of Slack-64. Maybe package sets are still needed for Slack-32, but I don't know since I don't use it.

1 members found this post helpful.

You figured out that if the maintainer would accept the proposal from this thread, there is no more need for splitting the packages in folders/sets and maybe no need even for the tagfiles?

Imagine all packages put in a single directory "slackware", the installer shows a list of groups to be installed if not all, then with grepping in the *.txt files, merging all results and doing unique and sort, you obtain a nice list of packages to install.

Leaving the heated thoughts away, I think this will be a great improvement while simplifying the things. But that's me, of course is my personal opinion.

He does not needs to adopt the Arch's PKGBUILD if he wants to change his workflow in some way.

He has at disposition Weapons of Mass Destruction, in the form of meta-builds from X11 and KDE, from years ago.

To be host, I expected, in those years, our BDFL to transform in meta-builds almost everything, because they are powerful like the nuclear devices.

Nice idea. BUT, even maybe that concept could be used the way you describe, YET I do not proposed changes like that. Lets be clear here.

My idea is all about a way of storing information about a particular package purpose, not about resolving dependencies, automatically or not, or changing the installer and putting all packages in a single directory.

Actually, I realized that whether the maintainer accepts the proposal or not, (1) the existence of package sets run counter to the recommended/supported installation, and that they should probably be removed to eliminate any confusion on that point, and (2) paring down the install should be left as an exercise for the system admin/user.

Tagfiles are still useful, and while I've never really played with them, knowing the build dependencies for packages I don't want should make them reasonably easy for me to write if I was so inclined. That's just more work than I can justify for MY use case. YMMV.

Darth Vader, I am curious, how would you describe the purpose of let's say libpng and harfbuzz that's not already covered by PACKAGES.txt?

I am sure that if I decide I do not like them, and uninstall them, I will need to do a lot of recompiling of other software, at the very least.
Of the two I suppose that libpng will be an optional dependency a few times more often, for example imagemagick might accept being recompiled to 'only' support all the other image types. But I'm not even sure of that.

1 members found this post helpful.

But you really believe that an unconditional full install is always better? What if this full install create huge problems in reaching the supposed usage of the installation?

Lets take the OP case. I do not try to defend him, but there is raised a real issue, which I would like to note.

If you had the patience to read some of his posts, he always talks about two things, when does not try to help someone.

One thing is that PAM addition would help the the users which use the Slackware in an environment somehow connected with corporate and office. Lets jump over this part, having no importance in our discussion.

Second thing about which he talks, is that he should continue to use KDE4, even after the adoption of KDE5, and have no importance his reasons to do that.

Could be a strong dislike for KDE5 or could be some proprietary software which he use for his activity, and that software must requiring KDE4. Who know? We could ask him to precisely known why.

Just like him, I am aware that the KDE4 will be replaced by KDE5, in one day. Sooner, or later will happen.

Trying to be on his skin, the question is how you completely remove the KDE5 and its dependencies, and to install back the KDE4, when this day come?

Which packages should be removed, to make that possible?

The problem is that no one know, even the maintainer claiming to not keeping a list of packages sorted by their dependencies, while the general recommendation, with winks or not, is to do it yourself. Sure, you do it yourself, but what you have to remove?

In fact, I will ask you if today we know how to remove the KDE4 with its every dependency?

Because I seen only a partial uninstall solution, given by Eric Hameleers for installation of KDE5.

I think there we hit the real issue: the Slackware is today dependent by KDE, and no one know how to fully remove it. Even the maintainer.

Or simply we cannot remove it without breaking the operating system. That's the real issue to think about, not the package groups or whatever.

Libraries

You know well about what I talk, BTW...

And I do not talk about resolving dependencies, automatically or not.

Instead, I talk about groups or "categories", just like you have a site, where you can have a image gallery, where you can dump everything having a page with 1200 images, or you can organize the images on categories, on sub-categories and so on.

Oh, and BTW...

You can safely remove both the libpng and harfbuzz, if your operating system purpose is just a headless network file server. Last I checked the BASH and NFS mount utilities does not depends on libpng.

@LuckyCyborg

Yes, I use for my job some proprietary software, software which require the KDE4 and Qt4. I like or not, I should continue to use KDE4.

Also I dislike that Plasma5, specially its wonderful stability until now. I use the computers for work, not as a plaything, where is no issue a "little" crash.

Worry not, I will find a solution to keep working the KDE4, at least for my own private use.

I am pretty sure that you will find a solution for your problem, as I see that you act proactively and I know that you are not a beginner in Linux.

But our problem will remain. In fact, could be removed the KDE? How? Which are those packages to be removed?

IF you ask me, to remove the KDE is simple, to remove all its dependencies is not so easy, because there are many libraries which are put in the L series, and they have a main utility for KDE.

Then is the Qt. For me is simple: I should stay with the Qt4 in the foreseeable future.

BUT from a general POV, you will treat Qt and its dependencies as belonging to KDE, or stand-alone support libraries?

Sadly, the problem is much more complicated than those libpng and harfbuzz things.

Overall you can say that KDE blended so much in the operating system, that removing it with all its dependencies, you have no more Slackware.

Absolutely not. I'm just making the point that a full install is the only _supported_ install. If we want to do anything else, we shouldn't be looking for the maintainers to make it easier. A little more on that below.

There absolutely is, and I've already said I understand the sentiment. He's just ice-skating uphill.

IMO, the real issue is that Slackware of today is designed to be monolithic. The package sets make it seem modular, but it's really not. It's designed to be installed and maintained as a whole, and anyone suggesting that the maintainer take steps to go against that vision is going to meet resistance.

That is more a consequence of its design. It's not meant to be broken apart and uninstalled in pieces, and the fact that it's even possible at all is a tribute to that design. I don't use either DE, so I absolutely understand a sentiment against having to install them "just because", but I'm not willing to jump through hoops to completely sanitize my system of them.

2 members found this post helpful.