[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ports philosophy

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?

Visit your host, monkey.org