Re: Moving mk.conf

[Aleksej Saushev <asau%inbox.ru@localhost>]

David Holland <dholland-pkgtech%netbsd.org@localhost> writes:

> On Fri, Dec 17, 2010 at 03:02:14AM +0300, Aleksej Saushev wrote:
>  > > (3)
>  > >
>  > >  - Put pkgsrc.mk.conf in the root of the pkgsrc tree, or in
>  > > pkgsrc/conf or some such place. Then it can always be found without
>  > > needing any path configuration whatsoever. For bootstrapped installs
>  > > it can safely contain the complete path configuration.
>  > >
>  > > The downside is that it doesn't allow avoiding baking paths into
>  > > bootstrap-mk files. Also, it complicates the lives of people who use
>  > > one pkgsrc tree with multiple separate $(PREFIX)es.
>  > 
>  > It complicates lives of all people using mk.conf, not only of those who
>  > use multiple separate prefixes. Configuration is mostly tied to prefix
>  > rather than to source tree, because most of those options change
>  > dependency chains.
>
> That's a good point, except that mostly it exhibits a shortcoming in
> the existing buildlink mechanism: ideally if I built e.g. gtk2 with
> non-default options that affect what should be buildlinked, and then I
> go to compile something that uses gtk2, the buildlinking should be
> done based on how gtk2 was compiled, not what the current option
> settings happen to be. (Maybe if these disagree, it should warn or
> fail, but that's a different discussion.)
>
> Also, your argument applies specifically to build options of installed
> packages. Other pkgsrc configuration makes more sense per-tree, such
> as PKG_DEVELOPER, PKGSRC_LOCKTYPE, PYTHON_VERSION_DEFAULT, etc.
> Arguably licenses do too.
>
> This is why I think the right approach is to support both this and a
> file in PKG_SYSCONFDIR.

Licences define what you may and what you may not install under prefix,
this is definitly not "per tree" configuration.

PKG_DEVELOPER and PKGSRC_LOCKTYPE are perhaps the only variables that
may be reasonable to set per tree, almost all variables are clearly
global or per prefix.

Alright, here're approximatly the content of my (generic) mk.conf:

DISTDIR - global
PACKAGES - per installation
BINPKG_SITES - global if empty, otherwise per installation
LOCALPATCHES - per installation, because if you set it per tree,
  you don't know what you're running.
PKG_RESUME_TRANSFERS - global
MAKE_JOBS - global or per installation, alternatively you set it on command line
PKGSRC_LOCKTYPE - this is rare variable that may be used per tree
CC, CFLAGS - global per package hacks, setting CC or CFLAGS, or both
CFLAGS, CXXFLAGS - 10 global per package hacks (to skip packages that don't 
resist optimisation)
CFLAGS - per installation
CXXFLAGS - per installation
PKGSRC_FORTRAN - per installation (or per package hacks)
FC - per installation (or per package hacks)
WRKOBJDIR - per installation, if you don't work on openoffice or mlton every 
day,
  it may be per tree though
CREATE_WRKDIR_SYMLINK - may be set per tree
USE_DESTDIR - may be set per tree
DEPENDS_TARGET - global or per installation
UPDATE_TARGET - global or per installation
PKG_DEVELOPER - may be set per tree
PKGCHK_CONF - global, fixes broken logic in pkg_chk that misplaces its 
configuration file
  into pkgsrc tree rather than associating it with installation.
PKGCHK_UPDATE_CONF - same global fix for installation state recorded by pkg_chk
SVN_CERTS - global or per installation, per package, 8 per package hacks here
PKG_DEFAULT_OPTIONS - per installation, since they change dependency chains
EMACS_TYPE - per installation, since you it affects your choices in other 
packages
 (e.g. emacs-w3m, flim &c)
X11_TYPE - per installation, since you can't install conflicting packages
MPI_TYPE - per installation, because wrappers and libraries conflict
PGSQL_VERSION_DEFAULT - per installation, because binaries conflict
PKG_JVM_DEFAULT - per installation
PKG_APACHE_DEFAULT - per installation

A whole section about options, with notable examples:

PKG_OPTIONS.emacs - per installation, determines your emacs' look and feel
PKG_OPTIONS.maxima - you can try to install maxima built with different
  lisp implementations, but then you need to split wrapper into separate package
PKG_OPTIONS.openmpi - per installation, changes dependency chains and
  your ability to install other packages (see conflict with libotf)

ALLOW_VULNERABLE_PACKAGES - per installation, 8 per package hacks
ACCEPTABLE_LICENSES - per installation if you work on anything to be
  used in commercial setting, they determine what is published in prefix,
  or distributed as packages, 20 occurences here

Total: of 212 lines in _pkgsrc_ mk.conf (I've split it from main mk.conf
to use more or less uniform environment on another, now defunct system)
there're only 6 variables to occupy 6 lines that may be reasonable to set
per tree. The rest (about 200 lines) is either global or per installation
configuration. These 5 variables are: WRKOBJDIR, PKGSRC_LOCKTYPE,
CREATE_WRKDIR_SYMLINK, perhaps USE_DESTDIR, perhaps PKG_DEVELOPER,
perhaps MAKE_JOBS.

I don't know if the logic behind PKGSRC_LOCKTYPE works at all; last time
I tried using it, it broke early.

USE_DESTDIR is more useful to set at least per installation, if not
globally, because it affects installation process.

The rest are: WRKOBJDIR, which I override on command line from time to time;
CREATE_WRKDIR_SYMLINK, which is set to its now default (again) value, because
of controversial changes long time ago, PKG_DEVELOPER, which is reasonable
to set per installation or even globally, and MAKE_JOBS, which may be easily
overridden on command line, and you _really_ do that frequently when
anything breaks.

I'm sure that if you want to move any configuration files or anything else,
that should be pkgchk.conf and corresponding file tracking the installation
state, which should move the opposite direction to what you propose, and
perhaps PostgreSQL database. This will serve users better than moving mk.conf
away from where it belongs to.


-- 
HE CE3OH...