[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
On Mon, Jan 21, 2013 at 9:50 PM, Aleksej Saushev <asau%inbox.ru@localhost>
> Please, try to understand the difference between meta-package and a
> collection of packages. One fundamental difference is that it has to
> install all of its dependencies in order to get built. We do have
> conflicting packages in pkgsrc, don't we?
I think this is a good point. I thought about the same when bulk-* appeared.
However, I think this raises much more fundamental pkgsrc's problem.
If run-time dependency is really RUN-TIME, there is no any reason to install
them at build time for building a meta package.
From practical point of view, it's easier to keep bulk-* as meta packages
and provide a way to not install "dependencies" at build-time thus avoiding
problems if conflicting "dependencies" appear. I don't think adapting bulk
build tools for this functionality is a right way to go.
I think you underestimate your own idea. Yes, on one hand a meta package
"contains" a list of packages. On the other hand, there are some other
applications. As you may know rpm or deb based Linuxes actively use so
called "virtual packages".
Virtual package provides some kind of abstract functionality, for example,
"mail transport agent", "window manager", "desktop environment" etc.
and some packages depend on such abstractions.
Idea is to provide more flexibility in specifying dependencies (e.g.
"we depend on graphic card driver,
whatever you have")
without specifying a concrete package (xf86-video-ati, x86-video-nvidia etc.).
pkgsrc doesn't use this term but it can easily be implemented with a help of
meta package and alternative dependencies.
Main Index |
Thread Index |