15.0 your teasing me now. getting hungry for a good pie.

The KDE is a pie with too much fat, according with my computer. Never able to run it, even it is somewhere here.

And I understand that KDE5 is even fatter.

Simple (according to you)... find out what dependencies in l/ are for KDE and are not needed and then take your tagfile for l/ and remove those packages from it.

===========================================

Your big intent in doing this is so you don't have to install KDE and it's associated dependencies, and you mention it has other implications allowing people to just have a LAMP server or something else, but where do you draw the line in what should be included in the installer? Should we support a non-development install (leave out d/ and assume they'll only be installing pre-compiled binary packages)? What about a multimedia install, leaving out all the server related things? Should it offer just a games install, and leave out all server, productivity, and development programs? What about an email server? mysql (well, mariadb) server? C++ developer? Web browsing?

You can have thousands of different categorizations and how should Pat decide what should be included and what should be discarded? And how is this easily done without dependency resolution? If you really think it is possible, you're lying to yourself. In reality, for KDE5, it might be easier to make a list of what it relies on that are probably independent of everything else in the system, but to go beyond that with other categories is just not easily doable without a list of dependencies.

You're pushing this for easy removal of KDE5, and if that list of packages is readily available, it might make this a bit easier, but that "list" might only be a partial list of what KDE5 needs over KDE4 and not an all-inclusive list. To get a proper list, you can't do it without a list of dependencies that you can cross reference for each package. Who's to say that a particular lib, while primarily used by KDE, isn't used by a different program? Is qt4/qt5 only used for KDE packages (someone else mentioned wpa_gui from wpa_supplicant uses qt)? So, if you remove qt4/qt5, are other non-KDE programs going to be broken?

Quit lying to yourself (and us) saying this is simple and can be done without a proper list of dependencies...

2 members found this post helpful.

It's just an obsessional delirium

1 members found this post helpful.

TBH, no guy consider funny the perspective to hard work several months if not more, in the near future, just to going back to actual state of facts.

I do not cry worried of the wellness of the OP, he's more than capable to run alone a distribution, if he has time for this, like he claimed.

Obsessions? No.

Using wrong tools? Yes.

And the maintainers are so friendly on helping him even a bit, even with a insignificant chunk of information.

You really think that Eric Hameleers does not understand the OP issue, while he's the most qualified person here to offer information about KDE5 structure and how to remove it?

Still I believe that the OP idea of groups is amazing, even it will not be adopted, more likely.

You believe and think what you want, me too

What's wrong with having an interest?

Sure thing, could be extended in many ways.

About WHAT installer you talk, man? Who said something about the installer? Me? NO!

My proposal is only about the ability to add a specific file in every Slackware package, process it by installpkg and adding a particular line in package entry from database. That's all!

I do not said or suggested what categories or groups to be added in that line, nothing!

I talked just about this features, which is probably about several lines to add in installpkg and tons of hard work from maintainers, even I can provide a suggestion how to do an initial population of those files.

WHY you ask me?, after all I am not the one who can decide which groups will add the Slackware maintainers, at the end of day.

My mere interest is they to show me which packages will/are added for Plasma5, in the rest I am not so worried if they invent hundred groups or only two.

The first one which I imagine to be prepared on that categorization could/would be KDE5, because it will be the next fresh whole whale to be added to tree.

Well, I accept that I would have some profit from this unexpected event.

Yes, knowing that a particular package was added for the KDE5 usage, will give me the ability to consider its usefulness.

MANUALLY, to not be worried about additional tools.

Again you ask me about problems which I am unable to resolve. I offer only the way, not also the solution, and I cannot ever offer it, as I am no Slackware developer.

If you are kind to think five seconds, instead to write shiny words, because you are an intelligent man, I am pretty sure you will figure out that that categorization is exactly the reverse of the dependencies resolution and much more generic. Also, much more easy to process via an BASH script.


Instead of telling on every package its dependencies, you have just to say its category, its purpose or call how you want. BUT, its all about where it belongs to.

At the end of day, IF that categorization fail somewhere, blame the one who will make it, not me.

@bassmadrigal

Just to clarify, I am the one who suggested that those package groups could be used by the installer.

Sorry, I read pkgtools and mentally thought the installer since you were not wanting to install KDE5 stuff.

So, you want all this extra work so you can uninstall Plasma5, which could be easily done by creating a blacklist file with the required packages. If you wanted to branch this out beyond Plasma5, you could create a site with various blacklist files that could be added to slackpkg. Then you just add those packages in those blacklist files to yours and then run slackpkg clean-system.

But how do you create those lists, ensuring it won't break any installed programs, without knowing what the dependencies of those packages are? Plasma5 is a bit easier since it is fresh and hasn't been added yet, so there's an easy to find list of software that had to be added to ensure it will work. But there could be packages that were added for KDE3 support and were used in newer KDE versions, but they aren't in the minds of Pat and team that they're "KDE dependencies" even if nothing else relies on them. The only way to find out what packages are only used for KDE is to have the dependencies listed. Otherwise, it will be a partial list, and other lists become impossible (without manually checking dependencies using ldd or various tools out there).

But to get it added to the correct category and not have it possibly break other parts of the system, you need to know what packages rely on it... dependencies. There would need to be a lot of work to check that any categories specified that when removed, aren't going to break other pieces of software when removed. And those categories would probably need to have dependencies too, because what if someone wants to keep qt5, but remove KDE. So, you'd need to separate out qt5 from KDE, but if someone removes qt5, they'd need to remove kde. And now dependencies have been introduced into pkgtools...

Or the blame could be on the person who suggested this on a distro that does not have an ability to check what dependencies are in the system

1 members found this post helpful.

Apologies... I started reading this last night and maybe I mixed up who stated it... or maybe I just read pkgtools and automatically thought of the installer. But thanks for the clarification

One of the reasons I asked about how you would classify libpng is indeed that it is needed for lots of stuff beyond kde, as others are also mentioning about qt etc in the context of whether dependency resolution comes into play or not. My file server perhaps won't suffer if I excise libpng as a punishment for also being a KDE dependency, but my print server already might: ghostscript (in ap) uses it too. Note that libraries that are really only useful to KDE users are actually mostly in the KDE series despite being libraries, awaiting a slackpkg remove kde command.

I'd say to anyone: just install libpng, it'll probably be useful. Most will agree there, but not necessarily when I'd say the same about phonon. Opinions will vary. PV seems to be saying we probably don't really need pam and you perhaps disagree. In Slackware, he has the final say for now, but Dlackware is there too, let's see if it takes off in a big way (I'm not rooting for or against it. I am happy that it exists but I have no interest in using it).

Many libraries and support programs will be required by multiple package sets, like libpng needed for stuff in x, xap, ap and e and probably more. Some development tools in d assume availability of stuff from n (network).
So moving stuff to 'sets that actually require them' means having the same package in multiple sets. Or there needs to be a separate series of "libraries you most probably need anyway", tagged "Libraries" if you want... but that is already what the l series is.

I think that the series back in the old days might have behaved more like you'd expect, but now a lot of Linux software is moving somewhat away from doing one thing well and will try to compile with support for x, y and z and whatever else it finds on the system, and the binary will then end up depending on the libraries.
And it's probably better to let it, otherwise people will complain "y is in slackware so why is b not built with y support?" while other people complain that c does not work without mentioning upfront that they did not install z because they thought it was probably not necessary.

There is a bit of an overlap between the people wanting to cut down their install to the barebones, and the people running into trouble, and the people not interested in first trying to reproduce their issue on a full install before asking for assistance.
So yes I am sure some experts here 'hypocritically' skipping e, f and kdei themselves while still not fully trusting first-timers to have excluded 'only some useless stuff'.

Now I would not personally mind if KDE and xfce4 would get the same treatment as MATE: different versions available only via 3rd party repositories.
But this would put a lot of burden back on alienbob and rworkman and others.
Firefox, fluxbox, texlive, emacs, thunderbird, gimp: if they all go to SBo and/or slackpkg+ compatible repos, I won't lose sleep. But if the Slackware base becomes too basic for some, I'm sure that this won't improve the reviews (OpenBSD get flak for it all the time, speaking of solid base systems to build on).

Great words, but you do what you do, and you go back to resolving dependencies...

Why you insist on that package dependencies and their resolution? For what?

To understand about what I talk myself in this thread, let's do a thought experiment:

Imagine that in -current, you create two new folders, "kdelibs" and "lamp", where you do symlinks to the packages which corresponds to those two new "sets", and somehow the installpkg is modified to register both the original path and the symlinked path in database.

That's all!

You can visually inspect those new "sets" or to consider their names from the installed packages database. Again, that's all.

No magic included there, no dependency resolution, nothing. It is just a packages categorization made by maintainers, having same dependency resolution support like the today package sets: next to zero.

Same works also my proposed design, over that files, instead of using folders and symlinks.

BUT, this categorization permit to users to know which ones are the packages required by KDE or to build a LAMP stack.

I for one, I consider that we arrived to need a better categorization of the packages. IF my suggestions are accepted or not, that's another story.

IF I have a particular advantage if this design is adopted, this is yet another story.

Or is a shame to have an advantage, while you offer something to others?

@Darth Vader

You can use hard links to do that. For instance this folder http://slackware.uk/slint/x86_64/sli...ng/slint/lxde/ includes only hardlinks.

This allows to type "slapt-get install-set lxde" and get them all (even without dependencies resolution, assuming that all other packages are installed).

But you could as well implement that with a set of tag files, or do I miss something?

Basically, in that unique "install/slack-groups" file you can specify tons of groups/categories. No limit for their number.

You can do precisely the same with folders and symlinks or hardlinks, but at a huge number of virtual "sets", the "information stored in files" variant is more clean. Imagine that you have one hundred virtual "sets" ...

Also, when using "install/slack-groups", the information is preserved even when the package is inspected out of tree.

The tags could be used only for a particular "view" of packages, that's why my variant is more versatile, because gives you a simple way to present tons of "views".

don't forget one for Multimedia, another for Productivity, another for Server, another for Education, another for Gaming, another for ...

And hope that your definition of a category isn't different from someone elses

Or are we to ask that Slackware ships with Multimedia_DarthVader, Multimedia_OldHolborn, Multimedia_SomeoneElse1, Multimedia_SomeoneElse2, Mu...

It all gets very silly very fast

1 members found this post helpful.