William A. Rowe Jr. wrote:
The last I heard, the 'rpm' project is open source, free to be adopted by
any platform.
Just because rpm is free to be adopted by any platform doesn't mean it
has been. Rpm contains features that allow the spec file to tailor
itself to its build environment, and I am
On Fri, Dec 4, 2009 at 12:59 AM, Graham Leggett minf...@sharp.fm wrote:
William A. Rowe Jr. wrote:
Ok, so they want to roll their own. Sounds like a maintainer issue. What
does this say for using our httpd rpm for an Ubuntu or other distribution
of linux?
Ubuntu is Debian based, and uses
Tom Evans wrote:
Really? It works perfectly on all boxes I use it on. What precisely
has changed about reading a pid from a file, sending signals to a
process, or spawning a process with specific arguments that has made
apachectl 'archaic and largely broken', I am intrigued.
And if you have
On Fri, Dec 4, 2009 at 12:37 PM, Graham Leggett minf...@sharp.fm wrote:
Tom Evans wrote:
Really? It works perfectly on all boxes I use it on. What precisely
has changed about reading a pid from a file, sending signals to a
process, or spawning a process with specific arguments that has made
On 12/4/09, Tom Evans tevans...@googlemail.com wrote:
Sorry, what has apachectl got to do with editing files? What has using
apachectl to stop/start a service got to do with scalability? You've
completely lost me here.
The only practical thing i can think of is OS vendors providing
separate
Graham Leggett wrote:
On a Redhat machine (Fedora/RHEL/Centos), search
/etc/rc.d/init.d/functions for functions called daemon, status and
killproc. These functions provide similar but incompatible
functionality to that provided by apachectl, and only exist on Redhat
derived machines.
Ok,
Gregg L. Smith wrote:
Original Message ---
Finally, I have yet to see any feedback on the pcre mandatory
dependency issue. Comments?
Personally, I thought your Monopoly metaphor was quite on target.
libz, openssl, lua = batteries not included
apr, apu, pcre = drive
William A. Rowe Jr. wrote:
Ok, so they want to roll their own. Sounds like a maintainer issue. What
does this say for using our httpd rpm for an Ubuntu or other distribution
of linux?
Ubuntu is Debian based, and uses the .deb packaging format, and startup
scripts derived from the Debian
William A. Rowe Jr. wrote:
I may be wrong but as an outsider looking in, I see you wanting to stop
maintaining/including the gear box and are instead spending the time on adding
more optional gadgets to choose from (some of the third party modules you've
taken over). In the end, I'd prefer
Graham Leggett wrote:
William A. Rowe Jr. wrote:
Ok, so they want to roll their own. Sounds like a maintainer issue. What
does this say for using our httpd rpm for an Ubuntu or other distribution
of linux?
Ubuntu is Debian based, and uses the .deb packaging format, and startup
scripts
minf...@apache.org writes:
Author: minfrin
Date: Mon Nov 30 22:53:43 2009
New Revision: 885606
URL: http://svn.apache.org/viewvc?rev=885606view=rev
Log:
...
Remove the use of the apachectl script, as a script calling
another script makes no sense.
I wonder if this is a good idea?
Dan Poirier wrote:
minf...@apache.org writes:
Author: minfrin
Date: Mon Nov 30 22:53:43 2009
New Revision: 885606
URL: http://svn.apache.org/viewvc?rev=885606view=rev
Log:
...
Remove the use of the apachectl script, as a script calling
another script makes no sense.
I wonder if
Dan Poirier wrote:
Remove the use of the apachectl script, as a script calling
another script makes no sense.
I wonder if this is a good idea?
apachectl does some things that httpd.init does not. For example, an
admin might reasonably expect to be able to control Apache's environment
William A. Rowe Jr. wrote:
Is it reasonable to simply provision apachectl as httpd.init, perhaps even
as a symlink?
Unfortunately not, no.
Redhat provides a library of functions to be used by startup scripts
that daemonise processes, keep track of pids, and do all the cute
displaying of OK or
Graham Leggett wrote:
We would either need to change apachectl to work like Redhat (triggering
a storm of protest from people who do use apachectl and would ask if it
wasn't broken why did you fix it), or change Redhat to work like
apachectl (not worth the effort).
Or change apachectl to
Original Message ---
Finally, I have yet to see any feedback on the pcre mandatory
dependency issue. Comments?
Personally, I thought your Monopoly metaphor was quite on target.
libz, openssl, lua = batteries not included
apr, apu, pcre = drive train not included.
And
On Tue, Dec 1, 2009 at 9:03 PM, Gregg L. Smith li...@glewis.com wrote:
And what is passing for an excuse for a local PCRE install
these days probably doesn't look like 7.8 or later, with
various fixes we are vulnerable to.
Isn't that the responsibility of the distributor?
This does not leave
Graham Leggett minf...@sharp.fm writes:
Redhat's init scripts don't work anything like the apachectl script, and
trying to call one from the other causes the exact problem you mention -
loss of environment variables, and all round weirdness.
Maybe I'm just slow getting back up to speed after
Dan Poirier wrote:
Redhat's init scripts don't work anything like the apachectl script, and
trying to call one from the other causes the exact problem you mention -
loss of environment variables, and all round weirdness.
Maybe I'm just slow getting back up to speed after the holiday, but
Graham Leggett minf...@sharp.fm writes:
Dan Poirier wrote:
Redhat's init scripts don't work anything like the apachectl script, and
trying to call one from the other causes the exact problem you mention -
loss of environment variables, and all round weirdness.
Maybe I'm just slow getting
Dan Poirier wrote:
Well, apachectl doesn't provide any of that functionality. About all it
does is source bin/envvars, if it exists, and then call httpd and pass
along any command line arguments. httpd does all the start/stop/restart
etc. logic internally.
So I'm still not seeing the
21 matches
Mail list logo
