A modest inquiry: the "meta" package

[Lew Pitcher]

Today, I installed four (self-built) packages on my Slackware 14.2 system
in order to play "MineTest". Admittedly, this was a minimal install; with
just those packages that MineTest absolutely required in order to
function.

In retrospect, while the three "support" packages each provide facilities
that will be useful elsewhere on my system, I don't actually have a use
for them other than to get MineTest working. So, the installation, for me,
is "all or nothing": all four packages, or none.

I thought to myself that it would be nice to have a way to provide a
Slackware "meta" package; a package that, through it's installation,
installs a number of /other/ packages. I could have a "MineTest" meta
package that, when installed via installpkg, would have installed the
four independent packages that make up my MineTest installation.

What I came up with was a simple package that consists of
a tmp/ subtree containing the actual packages to install, and
an install/ subtree with a doinst.sh that simply invokes installpkg(8)
on each of the packages supplied in the tmp/ subtree. This doinst.sh
would then uninstall(8) the package that contains it.
And, voila, a poor-man's Slackware meta package.

Of course, this is very rough, has no provisions for upgradepkg(8) nor a
removepkg(8), and is likely very fragile. But, for my experiment, it
worked.

So, I ask, has anyone here experimented with this metapackage idea? If
so, how did you approach it, what did you do, and how did it turn out?

[Henrik Carlqvist]

Post by Lew Pitcher
So, I ask, has anyone here experimented with this metapackage idea? If
so, how did you approach it, what did you do, and how did it turn out?

Yes, I have done custom packages that does install other packages from
their doinst.sh script. However, the purpose of those packages have not
been to group packages together so my cases has been a little different.
Also, my packages has not included the sub packages, instead I have been
able to rely on the fact that the sub packages has been available on a
mounted NFS directory.

One example of a package installing another package is a package which
checks if the machine has an nVidia card with the binary driver installed
and if so, updates the driver to a newer version.

For initial installation of packages with recursive dependencies I
usually rely on dependency tracking from something like the slpkg
tracking of dependencies from slackbuilds.org. I also have some groups of
packages in separate directories on the NFS server with packages.

As you say, package management is more than installing packages. It is
also about being able to update and remove packages.

regards Henrik