Thanks you for insight! I would really love to manage to bring up this program in the standard Slackware, when time will come, then I will try my best to solve this way.

While I do not ask you to keep those packages after Slackware adopts Plasma5, I would love if you will announce that in some way before doing it, as myself to know and backup your trees.

To be sure, a backup of your trees I make right now.

There are two parts to handling dependencies

• Working out the dependencies
• Resolving dependencies

Sure the groups themselves do not resolve dependencies (neither do .dep files on SalixOS) but to make the groups you need to know, understand and accurately record the dependencies and that is more than half the battle. It is also, the very thing you want the team to do.

1 members found this post helpful.

I think nothing should be baked into a package, info like dependencies, or categories, should be outside of a package. tools can pick up this external infos, extend them, change them, do what they want. this is more flexible and future save.

1 members found this post helpful.

Those are the changes required to the current installpkg from -current, to register the information about Package Groups, at least in my opinion.

I have no intention the package groups/categories/whatever to resolve the dependencies. I trust for dependency resolution the best tool I have at disposition: my own brain.

The groups/categories/whatever role is purely informative, as (me and others) to remember easily a package purpose.

For example, I intend to label my own custom packages like "KDE4 Compat", "For Job", "Web Development", etc...

Honestly, I only hoped, them to show me the purpose of (some) particular packages, in a human readable but machine compatible way.

Right now, I am focused in a way to to preserve labels attached to a particular package in the package database. BUT, meaningful ideas!

Still to note that at least personally, I would like to know precisely a package purpose, even for custom ones, made by myself, and their purpose to not be prone to unexpected/questionable changes.

Ugh, how can you still be missing this? I *know* that "package groups" don't have the ability to handle dependencies. I *know* dependencies won't be handled when you use those package groups. I've repeated this information back to you in my replies.

But you have to know the dependencies to *create* the package groups. Once they're created, they can be used by the masses without a thought to what the dependencies are.

We both know this and we've said that back to you in our replies. But you mention right there that you'll do dependency management manually using your brain when you *create* the package group. *That's* the dependency management we're talking about. Whether you use your brain or someone else's work (see links on my previous post), you have to have an idea of how a certain package links to the rest of the system to *add* it to a package group. We're not talking about someone trying to *use* a package group, but for the "maintainer" (for lack of a better word) to *create* it.

If you still cannot grasp this simple concept, then I am done trying to explain it.

I understand well your POV.

BUT, to understand also you my POV, lets make a thought experiment:

Imagine that you want to reorganize your packages dedicated the servers, i.e. LAMP, Mailers, FTP, etc.

And you want doing that today, with what Slackware gives you. WHAT you do?

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

I for one, I would create a folder named "srv" and move there some packages from N series. Which one? I would need to think about which one.

Introduce this new "srv" packages set a new dependency resolution support? I do not think so.

Someone should use his brain for. In this case, me.

The single result is that after installing those particular packages, one like me can inspect the record, and see that they are have in the entry "PACKAGE LOCATION" some particular folder name: "srv".

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

Now imagine that Santa Claus exists and he convince Patrick Volkerding to adopt that small installpkg patch (or something like) to Slackware, then P.V. wants to organize the servers from N set, in a new group.

He add to some particular packages a new label, i.e. "Servers", while they remain in the N packages set. Which ones? He would decide.

The single result is that after installing those particular packages, one like me can inspect the record, and see that they are labeled for "PACKAGE GROUPS: Network,Servers".

Would introduce this new packages group a supplementary dependencies resolution support? I do not think so.

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

In either way, someone (me or him) would have to make decisions, using already existent information, experience, or even tools.

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

We can continue another examples: with Didier organizing his multi-lingual support from SLINT, the Salix guys doing some nice categorization to their packages and so on.

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

I think that insisting on worrying about dependencies resolution from a particular "set", whatever it is hard-coded in a folder, or soft-coded in a file, is not fair for package sets of any nature, specially when important members of this community blame my concept as introducing the dependency resolution. Thing which it does not do.

The package sets, in any of their incarnation, are agnostic about dependency resolution.

IF a particular developer wants to create a particular package set, which is self-contained or not as dependency resolution, this is another tale.

That particular packages set itself has no clue that it is self contained or not, and no related information is stored.

For example, today the A set knows somehow and it can inform you that its self-contained, and XAP that is not self-contained as dependency resolution? I do not think so.

No, you really don't. You've missed just about everything I said in my post.

I already know this. It was in the first half of my reply. Package groups/sets/etc won't support dependency resolution. I *never* said the package groups would need to have dependencies. Once you let that finally sink in, if you go back and read through my posts again, you will hopefully understand I only talk about dependencies during the creation of that package set, *not* in the usage of it by the masses. Without even realizing it, you even stated you're doing exactly what I'm talking about with dependencies, yet you continue to disagree with me.

But, I just can't do this anymore. It has gone on too long with me just talking to a wall. Maybe it's a language barrier, I don't know. But I won't continue to repeat what I've said only to have you not understand it (heh, even though I did it again in this post -- I'm too stubborn for my own good and sanity).

Until the next thread Darth

1 members found this post helpful.

Darth, why are you wasting your time posting in this thread? Make a proof of concept, confirm that it works, then start adding the "slack-groups" information to all the packages in the distribution. If your idea is worthwhile, it will catch on eventually.

1 members found this post helpful.

BUT, I talked literally about organization of the packages sets in the creation of a particular packages set. Given as example for developers: me, P.V., Didier and the Salix guys.

I showed the proof of concept: that little patch. This is all it is needed, at least in my opinion.

Adding "slack-groups" to all the packages in the distribution?

Well, this is a bit a delicate tale, as I have no clue about the existence of a GIT or SVN repository which host the Slackware sources, for me to do pull requests against it. Thing which I will love to do.

You added four lines of code which currently do nothing. That's not a proof of concept. You want others to do the hard work for you. If you actually think it is worthwhile, you need to stop asking for handouts and start doing the work yourself.

Why I feel also that Patrick Volkerding will love to reject them, too?

I think he's right, he not promised more as code or features, from beginning. Look at the title of the thread.

Excuse me, but the title says "where could be", not "where must be". Being not native, forget my lacks of ability on handling English if I do a mistake.