On Fri, 26 Jul 2002, David Burgess wrote:

> > On Fri, 19 Jul 2002, David Burgess wrote:
> >
> > Issues that are at all controversial don't belong in a PR -- they need
> > to be discussed in tech-pkg first.
>
> Sorry - I got the order wrong.  I thought we documented our requirements
> and then argued about implementation.

I don't believe your requirements are yet clear...

> 3)  Include a mechanism that overwrites the /usr/src source tree from the
> installation script.  This way, the /usr/src tree agrees with the /usr/*
> directories.  This is my least favorite, but is conceptually the best,
> since the fidelity of the installed software base is based on the source
> tree, not two competing sources.

So, you want "/usr/src" to build and match the running system? How
about "cvs update", you want that to work, too? With this request,
you've stumbled into a reason why using "pkgsrc" to maintain the base
system is so bad...

> Having to remember that /usr/pkg/sbin/makemap is the
> way to make a new sendmail database on half of the servers, and
> /usr/sbin/makemap works on the rest is killing me, especially when
> "makemap" is still on the system and first in the path.

Just curious here: what's the downside of using the old "makemap".
Has the format of the hashed ".db" files actually changed?

> Of course, we haven't even started in on the OpenSSL Library fiasco yet
> (as a concrete example).  The OpenSSL library in the current system
> doesn't include MD4 - no big deal, until one of the programs in pkgsrc
> calls for it.  To solve the problem, I install the version from
> /usr/pkgsrc (which is, IIRC, the same version).  From there, it's just one
> mysterious library mismatch after another.  My IMP installations fell
> victim to this one a few weeks ago and I'm still not sure how to fix it.

This is news to me. I thought all that was missing from the base
system was idea and rc5 support. I'm going to leap to a conclusion
here: If you're linking against shared openssl libraries in ${PREFIX}
directly, and also against shared libraries which have embedded ELF
shared library dependencies on the base openssl libraries, it's
understandable you'd have problems. Even if I'm wrong in details, the
mere fact that you're having problems is an argument for fixing the
base system openssl and marking the package "not for platform
NetBSD-*-1.6*", not for discarding the base system openssl.

> Next, we get into Cron jobs - As a default, the crontab path doesn't
> include /usr/pkg until the end, so any management jobs I start up have to
> be fully qualified to work.  This works fine until the next upgrade, when
> I want to switch to the installed routine.  Of course, this really isn't a
> problem since the installation procedure wipes out the root crontab.

There's already an open PR on that last. [It could be solved by
letting sysinstall invoke "etcupdate", rather than untar "etc.tgz"
directly.]

Let's cut to the chase: If the NetBSD userland sources were updated to
the current level, that would solve all your problems. You could do a
"cvs update" in "/usr/src", build and install, and then you'd have a
current system which matched the sources in "/usr/src". That is the
chief benefit of having a unified system, in contrast with linux,
where you count on the distributor's package system for all updates.

The big problem with a policy of relying on pkgsrc for all critical
updates, is not (simply) that it resembles linux. There are mainly two
problems:

1) there's no pressure to update the base system binaries. While it's
nice not to have pressure, the opensource model relies on users using
the code and reporting problems and tweaking, and if they don't (or
can't) use it, it just rots, and

2) there's no pressure on the pkgsrc people (or the program's authors)
to fix the binaries to run against the system as released (your MD4
problem). You start with demanding that openssl be upgraded, and
before you know it, "this package requires xxx version of libc to
compile on NetBSD" (shades of linux, again).

The kicker is, it's easier for any particular developer to deal with
the code, than to deal with the code, plus deal with pkgsrc.
Maintaining the NetBSD userland (vs. pkgsrc) is not only better for
the committers, but for everybody who builds from source and patches
their sources, or who may patch their sources. So, your PR was
rejected because you failed to consider the obvious alternative. In
other words, you're barking up the wrong tree. Please make the case on
current-users for pulling up the openssl update to netbsd-1-5 (now
that NetBSD 1.5.3 is released), or updating sendmail in the base
system (and release), or request exactly those updates which would
make NetBSD more suitable for you.

By the way, there is an option to update "openssh" in the base system
using pkgsrc -- UPDATE_INTREE_OPENSSH -- but it's a bad hack which
sets a bad precedent, and it's sure to cause problems down the road.
To do that with a library like "openssl" is too horrible to contemplate.

Regards,

Frederick