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®istration 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?
- ports philosophy Chuck Robey
-
