I don't think Slackware is for you. I am not trying to be funny or elitist. I genuinely mean this.

3 members found this post helpful.

If you talk about a group creator who try to make a self-contained packages group, you are right.

But how many groups (or sets) are self-contained or need to be? Even in Slackware, right now we have only one: A, if I remember right.

Why I think that storing this information in the installed system is a good idea, at least for personal use?

For example, for my own use (I do not try to push it somewhere), I work to a small local site which shows me my own installed custom packages, categorized according their groups.

For me and my personal use, it has an utility.

Imagine a series of articles, in a news site, using either categories for organizing the articles, either putting a long list as index. I think is a difference on easiness to browse them. At least for me.

I hope you do not missed that here is now a theoretical discussion, a fun debate about a random subject, with interest for some. So, please take this way my words.

I ask for apologies, if you considered elsewhere.

I think is funny that in the last 25 years everyone was satisfied with the package sets, no one asked them to resolve dependencies, but now, when a little improvement of them was shown by someone, all orbit around dependencies. When even a simple mind like me understand that all is about one set, two sets, many sets.

Still, an enlightened mind could explain me the sense to store in package logs the "PACKAGE LOCATION", just comparative, after all I read in this thread.

I swear I see there the set from where the package was installed. It is not wrong to have it? According with @NonNonBa and others, it is wrong to store the sets name there, so I am confused.

To note that I do not question the Slackware design, instead I question some of the arguments from this thread.

3 members found this post helpful.

It indicates where the package was located when you installed it. It can be ".../slackware/ap/...-1.txz" as well as "/mnt/nfs/bob/...-1.txz", as well as "/tmp/tmp.TS9ubk/...-1.txz". It may help you to retrieve the package file but don't tell more than the sets (which, again, are not meaningful) about its purpose.

No, it's just about tagging packages. If LAMP won't work without pkg1, pkg1 must be tagged "lamp" whatever other tags it has, but a package doesn't need to be rebuilt to become such a dependency, that the point.

So the/a right way would be to have all the tags in ONE file apart, locally updated each time you have to search something. One wget and two grep should be enough to get a decent parser for this DB, then you can concentrate on the heavy work: feed it so many people find it useful. This model leaves your hands free, you don't have to convince anyone to do anything to prove it valuable.

1 members found this post helpful.

Again, you assume and talk about what I call "self-contained" group, like you say: the LAMP and all its components, libraries and dependencies. And again, you are right.

BUT, like I said no one time, there is no rule that a group (or set) should be self contained. Of course, not. Demonstrated even by Slackware, with its one self-contained set from 14.

You can invent "Mozilla Apps" which contains Firefox, Seamonkey and Thunderbird, but I hope we agree that this group does not contains everything is needed for running those applications.

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

Now, I will tell you some things what I do practically with those groups.

Who said that a package should and must contains a program or library?

A package could contain also a site. For example a Moodle site, which is an powerful e-Learning Platform.

And Moodle use plugins, which can be installed in the form of another packages. And so I do.

Then, I tag the packages which contains Moodle plugins, imaginatively named, guess how? as "Moodle Plugins".

Honestly? I am glad that I do this, because those academic guys love to invent obscure names for their extensions.

And in the day when you should repair a monster sized site, like a Moodle with all its content, courses, students, and so on, where they messed with everything, you will agree with me.

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

At the end of day, it is just a generic way to categorize packages, or how you say "tagging" them.

And that categorization is of course, as the packages builder needs, not necessarily to resolve a precise self-contained objective, connected with a public or private repository, or not.

Like I said in another post, may be laughable or not, but for my own use this thing is very useful.

1 members found this post helpful.

Let me give an example.

I just built a set of packages to be able to ship a MATE desktop in Slint. Here is the list:Is this "group" self-contained? This is debatable.

• One one hand, all the dependencies needed to get a MATE desktop that were not already shipped in Slint are included.
• Removing all these packages won't affect any feature of a previously installed system if it included only packages shipped in the previous ISO.
• But of course this MATE desktop works in top of a lot of other packages that make the "base" system.
• The deps that I have computed for these packages are accurate only in this context.
• And it is of course possible that a package of this set be needed as dependency of a third party package.

2 members found this post helpful.

@Didier Spaier

I do not think your package set/group is self-contained, or it could be.

It is a perfect example about what I talked.

In fact, I think that making a self-contained group is really delicate. And not really needed always.

For example, from where you should start the self-containing for your Mate?

IF one want to be absolutely precise on self-containing, I guess he should start with the Kernel and GLibC.

Not necessary. Assume in your DB you have the tags "minimal" or "recommended". If the new dependency bears it, then you won't add "lamp" because you can assume the user is informed it will probably get in trouble not having it. Now, if this package is so far only used by another server, it will obviously have to be tagged "lamp" because only the users of this server will have it installed while all the others will get their LAMP broken. You can't know once for all what information is useful about a particular package, so you need a way to update this on the fly.

"XFCE compilation made by Eric Hameleers" You can just ( cd /var/log/packages && ls -1 > $HOME/XFC_ERIC_PKGS.txt )
and there you have a complete list of packages -which is then easy to feed to installpkg &Co.

The idea of using links to package-names or db files is just as easily used without having to alter anything at all in pkgtools. Again, all the work is in compiling those lists of packages by-purpose, by-deps by-whatever-category. The lists will be useful or not -whether for just one person or many.

I recently praised a member who posted on one of the many minimal-install threads -I praised him because his list was truly concise and was clearly the product of real insight into what is needed and what is not to 'bootstrap' an installation under the most basic conditions. It was refreshing to see a real answer to that age-old quest for a tiny installation. Probably took the fellow a long time to learn that.

There's two ways to achieve an installation of just what you need and no more. The first and what most people do is to start thinning a full or nearly full installation. The second is to start with nothing or next to nothing, and add stuff to you get it all working. Either method is excruciating and costly -not only time, but nerves and maybe hardware! I'm pretty sure I drove an old drive or two over the brink by so many reboots and re-writes. It is well-proven that you can fry a complete system while trying re-compile slackware from scratch. Before trying that, finish the project of finding out just what is needed to boot to login on local hardware with no network or other exotic boot-time options.

Finding out how all that works and what is *not* needed, will help you then understand how one could re-compile a complete system -notice that I did not say re-compile a complete slackware system. Then, after all, since you are only one person, you'll understand why just one person would be crazy to do that very often.

Being 'The Slacker' is not the same as being 'a Slacker' -one mans' work saved is another mans learning experience. Slackware provides a rugged out-of-doors learning experience for the student who is ready. The KISS principle looks very different depending on whether you view it from the creator's side or the user's side. For the one it looks great: KISS and for the other it looks like this: SSIK -you do get to choose which side you are on, though. Thanks Pat, for all the things you didn't, don't and wont do! Yes, I *am* having fun, thank you.

4 members found this post helpful.

Here's what I'm hearing from LuckyCyborg in this thread:

If those were my needs, then I would absolutely not be using Slackware. I'd be using a distro optimized for a small installation footprint. Like Tinycore, maybe.

2 members found this post helpful.

This is a beautiful post. I thought you guys were all the same, I guess I was wrong. There is nothing wrong with being/wanting something different. If people helped each other more, it would be more easy to accomplish. What can I do? Grab a couple packages, find all dependencies and give Darth a list. Might be a small contribution but at least its something. Get a few hundred people to contribute a couple of packages and there depends. Shouldn't no one man have to do 1200 packages himself unless he wants to. Because some of you don't share his vision, doesn't mean you shouldn't contribute. To each his own.

2 members found this post helpful.

building tools to be used once and put in a drawer has been the Slackware way for years. I have my tools on the github and the bitbucket.
I do all this for me and my Slack. You may find your slack here also.
We was sober in college.

NOT

If I believe his vision to be useless idiocy, I won't contribute.

3 members found this post helpful.

Which will come first? The end of this thread, or The Apocalypse?

1 members found this post helpful.

Congtats, you win the award for the craziest thing anyone has said in this thread! High five!

4 members found this post helpful.