How about to switch to the usage of RPM as package manager and the RPM packages?

It can be used without dependencies resolution, of course. Still having available the Package Groups, so no more need for Package Series, as a RPM package could belongs to multiple Groups.

Also, the SPEC scripting language is powerful, specially made for splitting on multiple sub-packages and building for multiple architectures.

Using the SPEC scripting language will permit to have a UNIQUE source tree for both i586 and x86_64, maybe even for the ARM target. That will simplify dramatically the maintenance and the development.

----------------------------------------

The main advantage of this proposal is that NO PACKAGE should be added or upgraded, as the RPM is already integrated in Slackware since Ice Age.

There already is one single source tree for i586 and x86_64, that was the main goal behind the 64bit port or else Patrick would probably not have accepted the consequence of a double work load.

1 members found this post helpful.

Still remains as advantages the abilities of a particular Package to belongs to multiple Groups, i.e. could go well along Libraries, but also along Plasma Dependencies, then I can remove them graciously and flawless...

It seems to me, that this is one of the advantages of free software, you have the choice to use them or not

Tell me more about that, my French friend.

Specially, about: you should install in your computer the Plasma dependencies, you like or not, even they have ZERO usefulness for you and even they stay in the way of using "something" else, i.e. a sane DE like KDE4?

Is the forcing the users to install (at least parts of) a particular DE the proper way?

OR, will be there a proper way to simply install the professed Slackware 15, with no trace of that Plasma, wanting to use something else?

This does not matter, for me, I install what is needed

I propose the next version to be named Slackware Vista and adding a graphical BSOD, from following reasons:

- will crash often, if it will even boot.
- will boot only when it will consider appropriate, not when you will want.
- will be hugest monolithic shipped distribution release from the Linux ecosystem. E.g. would need 15GB installed for just browsing the Phoronix.
- will have impossible hardware requirements, like AMD Ryzen, 16 cores Intel CPUs and so on.
- just like the Microsoft Corp. do, the Slackware, Inc. will make a nightmare for users to use alternative software solutions.
- will be compatible with nothing.

1 members found this post helpful.

Ok, and if we stopped polluting, this post, now

3 members found this post helpful.

I take his post as a pamphlet, and more likely it is, but a bit of truth is in his words.

I for one, I believe that the "Install Everything" Age is about to end.

Long story short: we should clearly know what packages are needed for a particular task. I am happy you love Plasma, BUT I will want to use something else.

I have already said here, i use kde since 1 version, but each and every uses what they want....

Darth Vader, plasma's l/ dependencies would occupy about six pennies worth of disk space. How about I just send you six pennies and we can give the topic a rest?

2 members found this post helpful.

The issue is not those six pennies worth disk space, but that they will conflict well with the KDE4 ones, then to continue to use KDE4, I would be in the posture to hunt every one of them.

Perhaps you could parse the changelog and blacklist the offending packages in Current when they start to drop.

1 members found this post helpful.

Well, an interesting idea for reverse engineering the offending packages list. Thanks you! Brilliant!

2 members found this post helpful.

Uh, is "xf86-video-vboxvideo" what I think it is? Is it going to cause problems when I update the version of VirtualBox that's running my Slackware guest?

I'm used to to just reinstalling it from the "VirtualBox Additions CD" after each host-VirtualBox or guest-kernel upgrade.