Date: Wed, 19 Jun 1996 01:07:22 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Nate Williams <nate@sri.MT.net> Cc: Poul-Henning Kamp <phk@freebsd.org>, current@freebsd.org Subject: Re: tcl -- what's going on here. Message-ID: <22601.835171642@time.cdrom.com> In-Reply-To: Your message of "Tue, 18 Jun 1996 23:23:09 MDT." <199606190523.XAA04861@rocky.sri.MT.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> Bullying people around isn't the best way to get things done. It does
> do a good job of getting people angry though.
Well, I don't think Poul was up for bullying so much as he himself is
somewhat frustrated by the lack of response to previous attempts to do
something *like* this (note emphasis) and hasn't had much in the way
of response from people. In all fairness to Poul, we *have* been
discussing a scheme like this for over a year now and I've never seen
it come anywhere comfortably close to closure - the religious issues
never do, somehow. Sometimes the only way to break new ground then is
to hold up a lightning rod in a storm and weather the process as best
you can - what we generally come up with in the long run usually makes
everyone happy and everybody except the instigator (who's still
charred on one side) conveniently forgets the teething process. :-)
Now I've also had the benefit of having Poul talk to me about this for
a couple of days beforehand, so I know his intentions were purer than
you suspect - I don't expect you to have the benefit of the additional
context, so I'm trying to explain here.
I also knew that the uuencoded tarball was going to sit badly with
many folks but, since, Poul assured me that it was only transitionary
until we got through the lightning bolt stage, I didn't focus on that
issue, trying instead to keep the number of divergent mechanisms down
to a minimum by getting it to use bsd.port.mk.
I know that we'll work something else out for the tarball, even if it
just winds up being an imported, virgin unpacked copy of the tree in
some [sub]directory and the fetch/extract steps are eternally skipped.
I think we should also consider what we've gained here, namely the
"middle ground" between ports and src which we always knew was in our
future someday but have steadily tried to avoid. We knew it was in
our future because the prospect of re-bmaking every port we ever
wanted to ugrade, now and in the future, has traditionally _sucked_
and we've hated it from day one. I know you've always liked the old
scheme, but I don't think I ever saw you raise your hand to become
"bmake czar for eternity" either :-)
> BS. I've argued against through email and in personal conversation.
> But Jordan agreed so it didn't matter.
Oh c'mon Nate, this has nothing to do with some grand decision from
yours truly - this is simply the next logical step for things which
occupy the 3rd logical category of software - things which we need in
our base distributions but don't want to have to necessarily maintain
fully as FreeBSD components. Trying to deny the existance of a 3rd
category, smashing things into either /usr/src or /usr/ports, has come
at great cost on both sides. Either you're in bmake hell or you can't
rely on the feature at all because the ports collection isn't a
non-optional part of the system. This fact doesn't take an Einstein
to see, it's been obvious for a long time, and the fact that *neither*
of us has ever come up with a credible alternative is what led me to
stand out of the way when Poul decided to do what he did. Unless
you've come up with some way of eliminating the bmake-munging process
for ports like gcc and groff, I'd suggest you just let the man finish
what he started and admit to yourself that you've got no better plan
of your own to offer ("stay right where we are" being an option only
to those who don't have to do the bmake integration work every time :-).
Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?22601.835171642>