I can provide a small script which generate an initial "slack-groups" file for every package from Slackware, based in the actual package sets names.

BUT, to do this, I would need to know how will be liked to be named the initial groups. I.e. "L" -> "Libraries", etc...

BUT beyond that, I think the decisions have to made by the ones who develop the packages.

Of course he didn't promise to do anything. He made a proposal, and it was soundly rejected in post 4 of this thread. But nothing is stopping Darth from downloading all the source code for Slackware, setting up a git repository, and implementing the idea himself, at least as a proof of concept. If he refuses to do that, then this thread should have ended at post 4.

As the final processor is your brain, wouldn't it be simpler to get it in a file apart:

You could then easily find your kitten and moreover get a whenever-editable list of just the packages that have to be tagged. I myself keep such a list to start a fresh install.

If I remember well, the current sets are not meant to be meaningful, that's why a package exists only in one directory (e. g. Firefox is in xap/ while it could as well be stored in n/, php is in n/ while it could as well be in d/, etc.) They aim to split the huge directory the distro would be into several bundles you can search easily, not to categorize the packages or provide a db. xfce/ may stand for a category, but it makes no sense to (not) install l/, ap/ or n/ as a whole. The confusing thing may be the tagfiles (the only actual package set you define) have to be written one per directory, but in fact it's just an implementation. They could as well be a single file ignoring all about the tree structure (a package is by itself a unique key).


BTW, I think you could save a UUOC in your patch:

1 members found this post helpful.

I think that the first thing Darth Vader and his companions in this thread need to do, is:
- come up with a list of "slack groups" that are useful
- create slack-group information files for every package in Slackware (like a "mozilla-firefox.groups file containing "Desktop, Graphical, Internet" or whatever they coome up with).
- once they have done this categorization, they can do the heavy lifting of creating the package group files, and determining which of the packages in that group are depending on packages that are only in other groups, eventually writing down which combinations of package groups need to be installed together to avoid broken binaries as a result of missing libraries.

Happy hacking guys. Please don't post again until you have worked out the above. Then we can have a meaningful talk - until then, your talk is just air.


Edit: NonNonBa basically gave the same answer at the same time ;-)

Excuse me, I do not think I am the person qualified to categorize the Slackware, because I have no clue what 99% of its packages do.

But for xawtv slackbuild, which I downloaded it from slackbuilds.org,

then while I built the package, I created this file with a questionable correct
After I patched installpkg with the patch provided by Darth Vader, and installing the xawtv, the new line was made in package file from /var/logs/packages

His patch do what he said.

I think it is a step forward, before doing bigger things.

You done right, @LuckyCyborg.

Before invading China, one should at least check that his gun does not explode.

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

And the idea of a categorization of the Slackware is an interesting project. I hope the Slackware developers will have all support and will to do counseling for it, right?

But as a real project, not only a proof of concept, because for a proof of concept, no one needs to ask for a true categorizing 1200 packages, which is times consuming, then lets say "a way to ask them to shut-up".

Could be done starting in small portions, initially.

Secondly, there is easy to map all those existent packages to their existent sets (folders after all), and to generate 1200 group files.

BUT, the question is what you do with them?

Just repacking the packages, then publish them? Could be done, but they will be Slackware anymore, even if the original was? Could be trusted for testing?

Rebuilding the packages from sources, and patching the Slackbuilds? Another idea, and yet another Slackware derivative, even it will be ephemera.

Writing from scratch the categorization, as we like? With longs debates about every one of those 1200 packages? Could be fun, and can generate the longest thread ever from history, but how proper will be it, according with original developers intention?

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

I think the beginning should start with small steps, first preparing the tools. Secondly, testing the tools. Thirdly, imagining what to do with the tools.

Then, if there will be enough interest, will be also this Categorizing Project and mass creation of group files.

BUT, I hope Eric remembers, I said no one time: I will not fork (again) the Slackware (or another distro), because I have no time to dedicate for.

Then I will not enter in this game. At the end of day, I am just a poor Romanian, which will love to dedicate for his passions, but life is harsh.

Thanks for ideas!

The new patch proposed for installpkg is the following
Thanks to @NonNonBa, who has a brilliant idea which works perfectly.

Again, it is all about registering some additional bits of meaningful information in the package record, mainly for your eyes, not for automated tools.

Look, adding a bit of code in the package installer which manages a bit of data would be a snap. However, producing those 1200 files with that bit of data is a herculean task. The build process for packages would have to be extended to produce that data in the first place. There's only two ways to get that -you either hand-edit those 1200 files and add a line to every build script which will include it. Or, you devise some sort of 'clever' way to steal that info from other sources (like rpm spec files or debian control files) or generate that info -but still needing to take into account weaknesses in your detection method, or arbitrary things which must be mixed with or added to the generated info.

From the sources you could get some help by reading the 'Categories' section of any *.desktop files. Beyond that good luck -unless you can write code which makes sense of README files! Actually desktop files will help you with the purpose of the program too. But if it's dependency info you want, you can only get that by cross-referencing a database of lists of files included in each package. Then you can feed that info into your groups or dependencies. But bear in mind that any dependency info you generate has to be done at the time the software is compiled and packaged. Anything else is pseudo-information.

I do know what I'm talking about, BTW as I am on my 3rd design of just such a build/packaging system. It provides quite comprehensive information about each package, but *does NOT do automatic dependency resolution* -at least not yet. Since I know that the real job is in gleaning, combining and generating that info in the first place, I have concentrated on getting the build process geared up for that. Simply running a global rebuild of all packages is quite a job -having to re-do that every time you make a change in your db layout or content is maddening.

What I find to be the most useful info is the build-dependencies and build-order which I get from dependency trees. My system also reads executable scripts in the package to determine which programs/packages they need installed. All very nice -really interesting project. But I would never suggest anything like that for inclusion in slackware. Things like 'l=libraries', 'n=network' are simply information overload here -hehe. And real, reliable *information* about conflicts/suggest/recommends/depends/frowns-on are tabu hear. Even a thread about a 'minimal install' gets bogged down in 20 pages of 'yeah, but', space is cheap, why in the world would you want to do *that*?

Oh, about that 'frowns-on', that's a dependency qualifier which could be given to things like 'sysvinit', udev and others -each of these packages 'frowns-on' on 'systemd' as well as conflicting with it! Under Slackware, that label would be useless as every bit of slackware frowns on systemd, ummm, at least for now... I'm still sore about udev replacing hot-plug, Pat.

4 members found this post helpful.

ok Darth we all took the bait define "group" PLZ

It is like marking the cows.

Those three are the cows of Aliosha, those two of Ivan ...

input that in a terminal.

It always boils down to this, right? You have big wishes, voiced in capital letters with abundant use of color. You demand, you request. But it is never you who should do the work, instead the Slackware team is supposed to stretch thin and cater to your demands?

Patrick is our distro's Benevolent Dictator, he decides what goes into Slackware and it is perfectly clearly written that changing the package tools with your proposed extensions is not going to happen. You can write patches for installpkg but that is time wasted.
Instead, in this here Slackware community, good ideas are brought to fruition by joining forces and producing something new that makes all our lives better - on top of what Slackware and its developers have to offer. For instance, an extension to slackpkg similar to slackpkg+.

You stick to your beliefs that the modifications you propose have no relation to adding dependency checking, Yet that is exactly what your proposal is. Since you are not able to comprehend this, I will stop posting in this thread because this is just wasting my time.

Don't keep pushing, it will work to your disadvantage.

1 members found this post helpful.

Thanks for insights! Coming from a seasoned developer like you, they are even more valuables.

I know well that adding a bit of code in the package installer which manages a bit of data would be a snap. That's why I said from beginning that this part is simple.

Also I know well, that producing those 1200 files with that meaningful bit of data is a herculean task.

Not the part using a script to generate 1200 files which map actual sets in some way. This could be done in several hours.

The herculean task come after that, adding the smaller categories/groups, but also the depends on philosophy.

Sure thing, my philosophy is different of other ones. So my categorization would not be liked by others.

BUT, first of all, I arrived at conclusion that I need myself a way to categorize my own custom packages, made by myself for myself. Which are not in a small number.

What I try to label on this categorization? IF you leave it on my hand, it will be their purpose. If you wish, I am older now, I need a way to write down in an organized way, the purpose of those many packages which are added to my work. 10 years ago was simple to keep everything in memory, now maybe I will forget something.


Secondly, I like or not, I hit minimal installations. Even I catch a small job as building a VPS for a website, there should be only the packages which do the job.

In the servers, they consider everything else which is not necessary, as unwanted software. Even the GCC is an unwanted software in a server, because it could be used to compile parts of a rootkit. I know that is unbelievable for some, but in servers, even GCC is a security issue.

There is no room for tons of editors, for GUI things, for alternate shells, or any nice things which we appreciate so much.

Sometimes I manage to get projects where I can use Slackware. BUT, to use Slackware, I need to know precisely which one are the packages I need, which do every package, everything else should go.

That's why most likely my packages categorization would not be liked by many.

BUT, I believe that today I for one, I need it. And I believe also others need it, because I do not think as being as an genius with special needs.

Eric, I got it already that Patrick does not agree with this particular idea. I do not push for it in Slackware. I am not a kid to not understand his decision.

What I do is to share this idea, just like you said, and maybe other will help its polishing, even with ideas. And improving/developing it.

Personally, I use this categorization since several months to categorize my own packages, and at least for me, it is useful.

Even it never will adopted by Slackware, who know? this thing could be useful for one of its derivative...

Or maybe in a day there will be this Categorization Project made by those interested, including me?