[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/42263 (add PKG_OPTIONS to meta-pkgs/php5-extensions)
The following reply was made to PR pkg/42263; it has been noted by GNATS.
From: Aleksej Saushev <asau%inbox.ru@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, pkg-manager%netbsd.org@localhost,
Subject: Re: pkg/42263 (add PKG_OPTIONS to meta-pkgs/php5-extensions)
Date: Wed, 04 Nov 2009 16:28:14 +0300
> On Wed, Nov 04, 2009 at 12:00:07PM +0000, OBATA Akio wrote:
>> On Wed, 04 Nov 2009 20:35:01 +0900, <diro%nixsyspaus.org@localhost> wrote:
>> > That is exactly what i'm proposing: an easier installation. There
>> needs to be a
>> > medium between "install fscking everything" and install what you want
>> > without a) having to maintain a private package b) recommenting a
>> Makefile upon
>> > unpacking a new pkgsrc quarterly release. pkg_chk is also not the
>> solution i'm
>> > going for here.
>> Why not pkg_chk?
>> What is the differ between "set module name to PKG_OPTION" and "set
>> package path to pkgchk.conf"?
> Because i do not use pkg_chk. pkgchk.conf is another config file i'd have to
> write and maintain when i already use mk.conf. I do not need two config
> files to
> manage my packages.
I wonder how you deal with the need to maintain rc.conf, resolv.conf, ntp.conf
and a number of other configuration files in /etc instead of using single
registry database. Multiple confiration files should not be an issue already.
>> > Also, please do not be in such a rush to close this PR. Allow some other
>> > developers to view it first and see the value in this if you're having
>> > difficulty understanding it.
> I understand the initial discussion here; however, that package in question
> of four dependencies. meta-pkgs/php5-extensions is ~50. Why cannot an empty
> PKG_OPTIONS for meta-pkgs/php5-extensions default to building everything and
> otherwise could be set to build a few modules? Why are we holding onto the
> that a meta-pkg is everything and cannot be tailored? There is already a
> of packages which work in a similar manner. Why not this one?
Your PR is more general, it affects more than this particular meta-package,
if you want to propose general way, it is better to discuss it on mailing list,
which is more convenient and more appropriate. As for now the discussion
is counter-productive: general consensus is what I said above, meta-packages
are here for no-configuration cases, there're more appropriate ways to
configure the set of installed packages.
Main Index |
Thread Index |