On Wed, Sep 05, 2001 at 02:07:41PM +0200, Karsten W. Rohrbach wrote:
> Robin S. Socha([EMAIL PROTECTED])@2001.08.30 09:15:03 +0000:
> > * Peter van Dijk <[EMAIL PROTECTED]> writes:
> > > Basically, [the port maintainers] are too stubborn to create a port
> > > that installs according to djb's instructions, with a big fat warning
> > > or *whatever*. I think it's stupid, but that's just my two eurocents.
> > It's not just stupid, it's entirely brain damaged, because a port (unlike
> > a package) does not fall under DJB's redistribution restrictions (the
> > Debian .deb uses the same mechanism AFAIK). Whatever.
> i wonder what is wrong with
> #!/bin/sh
> cd
> mkdir djbsrc
[...]
> make setup check
[...]
Easy, the install locations doesn't comply with hier(7) and it isn't clear
wether a port changing them is legal or not. So djbwae is out of the tree
until he has license that clearly states what is allowed or not.
> well, if you gotta throw this into a Makefile to be perfectly content
> _and_ patch the source to install into different paths, then you're
> hosed anyway -- depending on the number of systems you administer.
> IMVHO, qmail belongs into /var/qmail -- and that's where it is on all
> the machines i log on to. no matter if it's *BSD/Slowlaris/HP-UX/AIX or
So. IMHO 3rd-party executable like qmail-send belong in /usr/local/bin/, and
that's where all software puts it's binaries, be it [add you favorites here].
I use more packages than platforms. So, for me consistency within the system
is far more important than cross-platform compatibility.
It's that easy: the OpenBSD ports tree rules and djbware rules don't fit and
thus djbware is removed. Why don't you get it? Anybody can still install
djbware from source. Or keep local ports + packages. Or whatever.
Stop this discussion. Everything is said (most on [EMAIL PROTECTED],
www.openbsd.org/mail.html has links to the archives).
> whateverIX[tm]... dan's policy just reduces TCO in a very simple manner,
> just as a side effect of his way of installing things.
> if the people don't understand that fact, it's their personal problem.
This isn't a fact, that is highly environment dependent. In my env it
highers the TCO as nearly all services run on OpenBSD. Consistency within
the system lower my TCO, cross-platform compatibility not.
> the recent drop of ipfilter is in no way 'justifiable'. it means: one
> more stupid packetfilter to deal with, to learn, to debug ;-)
pf looks far better than IPF ever did, even in it's early days it's in know.
And as config file sytax is nearly compatible (the incompatible parts made
them more consistent and only apply to ipnat), so the l;earning argument
doesn't count.
IPF had to be removed. We distributed a modufied version which wasn't
allowed that time. And, more important, it conflicts with
www.opwnbsd.org/goals.html.
> SECURE_OTHER_UNIX=FreeBSD-RELENG_4
I beg to differ.
--
* Henning Brauer, [EMAIL PROTECTED], http://www.bsws.de *
* Roedingsmarkt 14, 20459 Hamburg, Germany *
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)
