httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <...@engelschall.com>
Subject Re: binbuild.sh: Script for building binary tarballs
Date Fri, 05 Jun 1998 19:37:59 GMT

In article <35784026.E2C028A4@Golux.Com> you wrote:

>> But with the usr/local prefix the people see that this stuff has to live under
>> a usr/local prefix because it was compiled for this path. And because the
>> prefix is usr/local and not /usr/local it _can_ be extracted by non-root, of
>> course. Else I see the next PRs coming where people ask why they cannot just
>> extract the stuff under /opt. With the usr/local prefix they cannot do this
>> immediately.

> What do you mean it "has to live under" usr/local?  If there's anything
> of the sort in this then -1 right now.

> Yes, it *can* be extracted elsewhere, but *I* see the first thing
> happening is people getting irritated because it puts two extra
> levels under their cwd, when they then have to take manual steps
> to remove.  And if moving it elsewhere is going to break it,
> it's no good.

> I suspect the only thing that cares about the built-for path is
> suexec, right?  Which I don't think is sufficient cause to warp the
> entire packaging paradigm.

Yes, suexec and when you move it elsewhere you have at least to provide -d or
-f options to httpd, etc. And the paths inside httpd.conf are for
/usr/local/share/htdocs etc. Sure, it can be used elsewhere but not without
manual tweaking. That's the reason why I personally would like to see
usr/local in the tarballs because this shows that that's the compiled prefix.

> We've gotten PRs forever from people who unpacked things in
> weird ways; those aren't going to go away no matter what you do.
> Packing it in a weird way will only add to the issue, because
> people will complain about that, as well.

Another point of view, sure.

> All that was pointed out (by Marc?) was that binbuild.sh probably
> needed some tweaks to get it to work right with 1.3.0.  What I'm
> seeing here reads like "APACI cures all ills" and forcing the
> users to do things a particular specific-to-APACI way.  Maybe it
> IS a better way - but introducing it with no notice in a major
> release like this, surprising at least some of the people who
> develop the bloody thing, is *not* the way to find out.  Maybe
> I'm full of red ants, and our users will love this.  I just don't
> think we should take the chance.

> Can we find some middle ground here?

Puhhhh... feel free to provide one, yourself ;-) I just hacked the binbuild.sh
with Marc for 1.2.x. And now for 1.3.0 I looked at the stuff and though it can
be done easier and a little bit more straight-foreward. Although the script
uses APACI I never said that "APACI cures all ills". Take my version or
provide a better one, Ken. But please don't flame me because I provided my
variant. I always think its better to have one than having no one.  And unless
someone other jumps in and creates a different (and of course better) variant,
I see no reason why I should not post my own variant (which, of course, is the
way I personally like it).

I'm not sure what the real reason is that you are such sensible about
solutions posted by me (perhaps my solutions are always not really good or too
restrictive or whatever), but please always be constructive, i.e. help
together to push out the Apache 1.3.0 baby in Brian's timeline. That's all I
want to support. Hmmmm.... seems like it's better when I stay out of the
binary tarball generation precedure in the following. I really don't want to
bother people with APACI or my solutions.

Hmmm...
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Mime
View raw message