ports philosophy

[Chuck Robey <chuckr_(_at_)_chuckr_(_dot_)_org>]

I just got a nicely worded letter from someone, who's prodded me into 
trying once more to ask a ports-philosphy question.  It's a question of 
how much control to allow a user, for ports.  The person I was chatting 
with seemed to be of the opinion that the system ought to hage sole 
control of all common area software, areas such as /usr/local, or opt, 
or areas like that.  This means allowing, by means of archtecture (not 
just root control, but iron architectural control) whether or not a user 
may have his own system.

I'm arguing here that such a system is very hostile to programmers, and 
that there should be some method allowed, for a person to be able to 
tell the system, for  particular file, that the user is to be allowed 
control of that file, and not the system.  I want to be able to say, for 
example, I have installed libtcl.so.84.1, and not you, but please use it 
to satisfy calls for (give a sed pattern that finds libtcl.so.84 well 
enough).

[Let me emphasize that above a little more: un my mind, you're making a 
system that's hostile to progammers, unless they are willing to program 
for OpenBSD itself.  Actually using OpenBSD as a base for their own 
projects, it's such a hostile environment!  The ports system legislates 
against all incursions against it's iron control.]

I suppose it's possible that such a override&registration method might 
exist, but if so, I can't find it.  The system, as I see it, has been 
crafted so that no programmer can have any control at all, and the only 
person who wins is the sysadmin, who no longer has to worry that anyone 
might possibly make any changes in his system,  the control is not just 
via root password (which in itself is a system that is strong enough for 
this task.  Root password isn't the strongest method in the world, but 
it's strong enough for this purpose.

If you are making a system that allows no users to have any control even 
if they're the root user, then you are making a system that is highly 
hostile to programmers.  What you ought to expect, then, is for folks to 
install your system, learn what kind of control they're giving up, and 
then those people will be leaving the system, just as soon as an 
alternative shows up, because THEY LIKE TO PROGRAM.

I just can't see why adding in a program, something akin to GNU's 
pkgconfig idea, is such a bad idea.

The way I see it working is, for every dir in the list of dirs in 
LD_LIBRARY_PATH, there should be dir ${dir}/opkgconfig (gnu already uses 
pkgconfig, so I added a "o" prefix, I might even agree to 
"openbsd-pkgconfig" subdir to every dir that shared libs are  in.  Then, 
for every shared lib that the programmer wishees to have control over, 
the person must have a file of the form (pkgname.pc) , example, 
libtcl.pc.  Inside this file would be information that you would want to 
pass along to the system, if it's going to surrender all control, such 
as a sed pattern that you'd want to have the file protect against 
incursion on, all the CFLAGS to use, if you want to compile in the 
program, any LDFLAGS likewise, installation dir, include dir, (and yo 
can probabluy figure in anything I;'ve forgotten).  Making a small shell 
utility to query the .pc files wouldn't be all that hard, would it?