But they are intended to make it easier to install subsets: it's just not a complete solution.

E,F,KDE,XFCE, and a few other minor ones can all be left off if someone doesn't want those subsets. What they're not is a completely self contained selection point and things like the L set are a little more complicated.

As an example, this is how I currently keep updated with current:
Yes, there's some KDE specific stuff in the L set that I don't really require, but I don't need to remove it all to get benefit from only syncing a subset. I save a lot of bandwidth and disk space -- though disk space is not all that relevant these days -- doing this.

No longer having sets at all in the way you describe would have a huge negative impact on my admin workflow.

To be fair, I understand the original intention was to modularize the _distribution_, not the installation. The present incarnation of the package sets seem to have been dictated more by the space available to the medium back in the day than by any desire to allow selective installation.

And there's the rub. It's possible to use package sets the way you (and I) do, but the fact that they're not self-contained leads me to the inevitable conclusion that they were not originally designed for that.

L was the subset I specifically had in mind. A possible solution might be to move the libraries in L to the package sets that actually require them, so that leaving out a set would be closer to a modular install.

I get that, and I'm not really advocating their removal. I'm just making the case that the recurring threads such as this one arise from a "misuse" of package sets to achieve a result not strictly in line with the maintainers' intent, and the resistance that these threads almost universally meet stems from the maintainers staying true to the vision.

For example, look at Alien's rsync patches script. There's no check for installed packages, because the assumption is a full install. SBO assumes a full install. Any support questions will inevitably arrive at "did you do a full install?" Now, slackpkg checks installed packages prior to updates, but I'm not really sure why, tbh, since it seems to be almost supporting partial installs. Another minor inconsistency that adds fuel to the controversy.

Prime computation based on available evidence: Full installation is the intended implementation of the designer's vision, and anything else will be left _solely_ to the admin.

I'm just saying that the presence of the sets themselves leads to an ambiguous understanding of why they exist, and to be "philosophically" consistent, they should probably be removed entirely and any modularization should be through tagfiles.

I'm not a maintainer, so obviously my interpretation of the intent and vision behind Slack is worthless in the grand scheme of things, but everything points to any request of the maintainers to more directly support modularization will be met with "be my guest."

3 members found this post helpful.

If it works perfectly, someone will reinvent it...

2 members found this post helpful.

Excuse my ignorance, but in this day and age, looks like everyone put accent on modularization.

We talked about KDE and Qt. Look what happened to them, they exploded in a myriad of stand-alone sub-packages.

Could be that the Slackware implementation meanwhile became obsolete and it should be updated?

You noticed that everyone evangelize the full install, but in practice they use partial installations?

I am an ignorant, but I seen there proposals and arguments on splitting the L set packages depending on their purpose, mainly console and graphics.

I do not think that the main issue is that the intended implementation is the full installation, and anything else left _solely_ to the admin, but he's left also with _no information_ about how to manage that.

And that happens in the day and age of a myriad of PPAs.

Ignorance can never be excused.

Slackware is not "everyone". Pity for you.
Slackware will remain without automatic dependency resolution which is a requirement for "modularization" as you call it. Despite Darth Vader's comments that dependency resolution is not relevant, it is. Define a "package group" as you want, and who is going to determine that you have not missed a package? Are you going to run ldd and readelf against every binary and library in your package group? Didn't think so.

If you think it is time to move on, why are you still here.

IF you are not comfortable with managing your Slackware system, do a full install as recommended. It is not killing your computer to have libraries you think you will not need. But Slackware is not sitting in your chair therefore it will not make assumptions about what you want to do with the system. You get the swiss army knife, do not whine about the amount of utensils it contains.

Like I stated in my first reply, find a couple of like-minded Slackware users, and sit together to write down a set of tagfiles, then setup a public repository and share them with the rest of this community. That is the Slackware way to solve your issue. Whining is not.

8 members found this post helpful.

Again, I think that the Package Series/Sets are not supposed to resolve dependencies, even in a rudimentary way.

I look at them as a way to categorize the packages, and that is not the same thing with dependency resolution.

Instead, it is more likely a description of their purpose. A label, not a dependency.

Also I believe that with a well made categorization, would be possible to partially modularize the Slackware.

At least, until to be possible to install it without KDE, X or whatever.

While I am generally in favor of modularization you have to realize that Slackware was not designed that way from the inception. Reading Patrick's answers in this thread should have already made clear that Slackware won't change significantly in that respect. So, if you want a modularized Slackware you will have to fork it, there is no other way.

I don't.

It has been already stated that a dependencies list of each package won't be provided by Slackware (but you are free to build your own and there are several third party tools that, although not perfect, can help you doing that). Beyond that, I really don't know what kind of information could help the admin.

If you want PPAs, I guess you will need Ubuntu or such. Maybe Slackware is just not for you ?

2 members found this post helpful.

That is an absolutely valid question, but given the only criterion that seems to be in play, the vision of the designer, the answer would appear to be "feel free, but not by us".

I have, and the dichotomy is indeed interesting. I would replace "evangelize" with "be willing to support", but the observation seems to withstand scrutiny.

There were proposals, and they were unceremoniously dismissed. It was re-reading Pat's response to it that in large part led me to the opinion I currently hold.

No information, no support, and no interest in providing support, yup. Full install, or we're on our own. Salix or another derivative sometimes crops up as a viable suggestion regarding the issue.

To be clear, I'm not saying one side is more correct than the other. As users/admins, we're free to do whatever we want with the distro we're provided. I'm just making the point that Slack is designed a certain way, and it's looking pretty apparent that any attempts to work around that design will have to come from the community.

1 members found this post helpful.

For any of us that have built source Deb's and source Rpm's know there is no magic nothing automated. It is a lot of work writing the script.

as Eric said we have tags. Write your tag out and use it. I am sure slackpkg or the installer can handle the groups "designated group folder name" tag .

Puppylinux checks dependencies by using the "ldd" command then offers a direction to what library to install.
Write a tool using "ldd" to install from your tags do it.

Brilliant, Drakeo!

You solved how to find missing dependencies for installing something. Then how you will do to NOT install something, like a particular DE, and all its dependencies?

Not because you are bad guy, but because those dependencies will conflict with the ones which you must use?

I.e. to continue to use the KDE4 while everyone else is happy that Slackware merged the Plasma5, just because your job needs that KDE4, nothing personal thought...

PS. No one ask you how to build the updated KDE4, but how to NOT install the Plasma5 at all.

Darth Vader you know and I know slackware is a source based system. So it is up to you to build and link libraries as needed. Many times in media stuff I had to recompile static so not to break third party stuff. Any one can build slackware.
Pat has chosen to put his puzzle together a certain way. We all can do that. The real issue is dynamic linked libraries.

How to bake a pie and how to slice it. mmm hungry

Thanks you, I have no problems to build what I need.

BUT, again. How to do to NOT install what I DO NOT NEED?

To begin with if exclude tags that use them.
write the script you can do it you wrote the tags in order of your build.
build the tool you built the tags in order of your baked pie.

I look at it as a pie "blob" the tags are the recipe. pkgtool puts tags in tags out.
write the tool to just a thought.

When Slackware 15.0 will be released, read CHANGES_AND_HINTS.TXT. Then:

• Figure out which added packages you probably won't need and/or could conflict with KDE4 and its deps. Just reading their description in /var/log/packages will give you a clue. Remove them.
• Figure out which removed packages you would need. Rebuild them from the sources in 14.2. This of course includes KDE4 and deps.
• If something is broken, find out which or the removed packages is missing, and reinstall it.
• Publish you results to help other people who don't want to upgrade to KDE5.

If anything, I think "you will do not need" in the future the packages which right now are there:

http://bear.alienbase.nl/mirrors/ali...rent/5/x86_64/

Look with big attention to those packages. They are your own enemy. Note their names while waiting their apparition in -current. Then apply them the Sicilian Welcoming.

1 members found this post helpful.