--pgp-sign-Multipart_Tue_Jun__5_13:10:23_2007-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Mon, 4 Jun 2007 15:37:20 -0500 (CDT), Jeremy C. Reed wrote:
Subject: Re: Default for PKG_SYSCONFBASE
>=20
> On Mon, 4 Jun 2007, Greg A. Woods wrote:
>=20
> > Keep in mind too that pkgsrc is intended to be portable.  Any platform
> > it works on may have any (or many) package(s) included in their base and
> > so packages should, by default, always simply use PKG_SYSCONFBASE=3D/et=
c.
>=20
> I would say that would be an argument to not use /etc/. Because novice
> pkgsrc users may have incompatible software using same configuration
> files. They might be incompatible simply because old versus new versions
> or maybe other vendors (hopefully not pkgsrc) may have incompatible
> extensions or changed configuration options.

I don't quite buy that.

In a production environment a good system manager would _never_ install
many versions of _default_ production software by using different
packaging schemes, or even by tweaking some build-time pkgsrc parameter
when building each package.  That would be disaster waiting to happen.

Furthermore if you have several versions of the same software installed
in a production environment using the _same_ packaging scheme then
generally you want the respective configuration files for each version
to have the same naming conventions as are used to separate all the
other files for each version and that generally means having all the
configuration files.  E.g. /etc/openssh-1.x/*, /etc/openssh-2.x/*, etc.

None of that has anything to do with whether or not any given particular
packaging scheme decides to squirrel all of the configuration files for
the packages it manages off into some unique place which reflects only
the packaging scheme's developer's silly ideas and not any other useful
functional difference.  In fact such things generally just get in the
way of sound system management.

I.e. in production systems the uniqueness of file locations and similar
such things, especially when all such naming is based solely on the
packaging system, is a very _BAD_ thing.

Consistency is what's needed for reliability, usability, and
maintainability of the production environment.  This is all about
operations of a production system, not about goofy developer
preferences.

If you're installing a package that may, or may not, have also been
installed in the base system then you want its files, and especially its
configuration files, to be consistently found in the same place, no
matter whether or not the new (or old) version being installed has
incompatibilities with the previous installed version.

The packaging system really should endeavor to make the resulting system
look and feel no different than if it were one consistent integrated
whole where everything was built and installed natively.  This is
especially true for any packaging system which aspires to be used by the
base OS to install base-OS components!

The idea I was getting at with my original statement above was more or
less exactly that which you mention next:


> On the other hand, NetBSD users have been confused by editing files that
> already exist in /etc/ but nothing happened because the didn't change the
> configurations under the PKG_SYSCONFBASE.

Indeed.  That's one of the reasons why consistency from an operations
point of view is far more important than goofy developer preferences.

If I install a new named using pkgsrc then at minimum it must use the
same configuration files (and /var stuff) as the base-OS version, even
if the new one is subtly incompatible.

I would prefer of course that the packaging system be aware of the
base-OS version and that it replace the original base-OS version
entirely, using the exact same pathnames for all similar files, etc.

The only real reason it's handy to have a unique $PREFIX for pkg stuff
is that the pkg_install tools are not (yet) aware of the base-OS
components.  If the base-OS components were all just pkgs, and if one
trusted the pkg_install tools entirely, then it would be irrelevant
whether a pkg came from pkgsrc or the base-OS and one would want all
software to be installed within the same consistent pathname hierarchy
regardless of where and when it was built or by whom.

In the mean time having a PKG_SYSCONFBASE and VARBASE settings that are
consistent with the base-OS software components is the next best thing
and at least the expectations of how any given system is managed can be
maintained consistently without having to learn quite so much detail
about base-OS software has or has not been replaced by add-on
components on each unique system.


> Another example is openssh with /etc/ssh/ where new versions of openssh
> have new configuration options that are incompatible with older openssh.

That's and entirely separate issue.

Let's pretend for a moment that all packages, base and add-on, are all
managed by the pkg_install utilities.  Let's say you install a different
version of OpenSSH which is not compatible with the configuration files
of a previously used version.  Will changing PKG_SYSCONFBASE solve that
problem?  No, of course not.  What if you want to have both versions
installed simultaneously, perhaps not just for testing but to put each
in full production use?  Are you going to have a unique PKG_SYSCONFBASE
set during the build of each version of the package?  That would be
ludicrous now wouldn't it.

This issue of incompatibilities between versions of a given package (or
even variants of similar packages) really must be solved separately from
generic pkgsrc build-time parameter tweaks, especially those which
control basic installation pathname prefixes and similar such things.

Binary packages should be consistent _by_ _default_ no matter who builds
them or in what kind of environment they are installed.

These kinds of incompatibility issues exist regardless of what tools are
used to install the software -- or even whether or not the same tools
are used to install the different versions of a given software package.

--=20
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>

--pgp-sign-Multipart_Tue_Jun__5_13:10:23_2007-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: YpFHomXeSvwVUi5hy4mQql+2t+u8wdl+

iQA/AwUBRmWY/2Z9cbd4v/R/EQIZ4ACgqAo0h+px/eSE1tqmbCMyoxaBy80AoMSC
jK5YR37/W2OqeLq5AkEh0LFK
=7kUY
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Tue_Jun__5_13:10:23_2007-1--