tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bulk-*
On Tue, Jan 22, 2013 at 05:41:36PM +0000, David Holland wrote:
> On Tue, Jan 22, 2013 at 12:37:36AM +0200, Aleksey Cheusov wrote:
> > On Mon, Jan 21, 2013 at 9:50 PM, Aleksej Saushev <asau%inbox.ru@localhost>
> wrote:
> > > 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.
>
> Yes, and as meta-packages are special-cased in a lot of ways already
> it's not necessarily a bad idea to just adopt this behavior.
>
> > 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.
>
> The other practical issue is that we don't have any method for
> handling lists of packages other than meta-packages; and, most
> meta-packages are in fact "lists of packages". The only thing
> different about the bulk-* packages is that installing them is
> basically useless.
Actually, there are the SPECIFIC_PKGS lists that can be placed in
mk.conf or equivalent, and then just issue a "make" from the top-level
pkgsrc directory, but that's not as good a way, I believe, as having a
separate meta-package.
In passing, someone has added (in 1.79) a question about why 4 separate
defs are needed - I thought that the names were a bit of a giveaway, maybe
I'm assuming too much.
> If you want to float an entire new scheme of lists of packges just so
> the bulk-* lists don't themselves have to be packages, be my guest,
> but it seems like a lot of work in pursuit of a minor abstract point.
>
> (Admittedly it is also untidy that at least bulk-large cannot itself
> be "built" successfully, but until we're down to no more than a dozen
> or so routine failures I don't see this as terribly important.)
One thing I like about the meta-package approach is that it comes at
bulk building from a user PoV. I accept what Aleksey was saying about
the conflicting requirements - if there are any, I'd expect the list
of packages to be changed, though. And, as David says, this seems to be
a minor point.
Best,
Alistair
Home |
Main Index |
Thread Index |
Old Index