It's you who says a lie

BTW, he made a reference to a cult series/movie: Firefly/Serenity.

Also it is a term in the urban slang, see there https://www.urbandictionary.com/defi...20is%20a%20lie

Ha ha! I changed my impression about the cowboys, either Texans or Russians...

Do not worry, see you soon, sixty two years, I've seen, heard and read, others

You are 62, my friend? Heh, I am also almost 50, not so young anymore ...

Yes, in two month, young man

The full install is just the way you won't have ANY further dependency problem, that's why it is advised for people not wanting to deal with them AT ALL (esp. if you are in -current). Now, I've been using Slackware for twelve years and NEVER did a full install. The way to follow is what I expose supra: keep a record of what you install, so you can generate the according tagfiles from it.

Get this record (ie. YOUR recipe to cook the distro) is straightforward: 1) install the XXX application package; 2) run it; 3) when it fails, look for the package containing the LLL.so.1.2.3 it asks for. The last step is easy to complete from the MANIFEST.bz2 file:

This should do 95% of the job, the remaining is why the record is a commented record (and why a 100% reliable dependency tracking is not trivial). This is moreover a good way to understand the structure of the system.

3 members found this post helpful.

Notice this only gives you the list of the installed packages of the group, and then won't answer to the far more interesting question "what should I install to get a working LAMP". That's why the package logs are obviously the wrong place to store this info.

But this is my issue, to know the _installed_ packages of the group, the response to "what should I install to get a working LAMP" should be given me by installer.

That's only partially true, if you intend a mass removal with no inspection, because you assume that the group is self contained and no packages are used by other groups.

BUT, WHAT IF the group creator write down every package needed to give you a working LAMP, starting with the Kernel and GLIBC?

The groups idea permit to associate a package to many groups, after all it was its main feature.

The group author take to mark every package needed for the purpose of the group, in this case having a working LAMP, would work well even with a installer which works like you suggested, because I guess there is also about merging lists.

BUT, if you try to do blindly a mass removal in a group made like I explained, you would put down the system, removing even the Kernel.

That's why I claimed that my take has mainly an informational role.

I.e. to show you the installed packages from a specific group, for your further inspection.

That would need metapackages like in Ubuntu, for instance.

This feature is not available in Slackware.

He talks about the groups idea, not about Slackware per se, but you are right, the Ubuntu or Debian use meta-packages for this purpose, while the RPM based distros, well... the package groups.

And where will the installer find this information? In a "DB" recording which groups any package belongs to. So, the most reliable and the only consistent way is to first ask to this (whenever-updatable) DB the names of the packages of the requested group, then to filter only the installed ones. Otherwise you can't never know if your logs reflect the current state of the distro (a package can become a crucial dependency of a group without being rebuilt).

He had an idea about putting the groups data in the companion text files and grepping the information in the same way, then when you update the packages from distro, you will update also the groups information to reference the current state.

While I agree that his way could work, note also my previous comment about a really big issue about blind removals via groups, because there is no dependency checking other than your own brain.

The info you get is not reliable. If the new package1 version now requires package2 to just run, you don't have to rebuild package2, so the information it will still share when you'll upgrade package1 will be outdated (it has now to be referenced in the same group as package1). This otherwise would require to upgrade the packages just to update their group info, which is IMHO insane (but still, it wouldn't have any sense to duplicate this information in the package logs, so you don't need to hack installpkg).