Re: implict and explicit requirements (Was: Re: HEADS UP: Apache 2.2 is coming...)
On Wed, Jul 11, 2007, Ralf S. Engelschall wrote: On Wed, Jul 11, 2007, Thomas Lotterer wrote: The topic is about how to handle with_foo for a with_foo_bar option that only makes sense in concert with with_foo. On Tue, Jul 10, 2007, Christoph Schug wrote: For me, it looks more like the second [implicit] case, but I might be wrong. If not, there should be some fiddling in the fixing implicit extension dependencies and correlations section, right? I remember the implicit dependency issue but wasn't sure what the best practice is to make clear to the user that with_imap_annotate implies with_imap. My ideas were: - use if with_foo || with_foo_bar in the with_foo logic this will build with_foo if only with_foo_bar is given but rpm -qi will show up with_foo=no. Bad - implicitly set with_foo=yes when the user chooses with_foo_bar AFAIK the current practice. Build and query ok, but somewhat magic. - make the package require itself, enforcing an explicit setting Something like if with_foo_bar then require self::with_foo=yes If the latter works, I'd prefer it. Never tested it. As I think RPM will not allow the latter, just use the second one. This is what we already have in a bunch of similar packages. Okay, I just commited it the secondy way [1]. Anyway, another disadvantage of this method should be mentioned. When altering options implicitly this change is not reflected in the package description, i.e. doing an 'openpkg rpm -qi php' still shows 'with_foo=no' even if it was triggered to 'yes' by enabling 'with_foo_bar'. Well, another question regarding both PHP packages, 'php' and 'apache-php'. Why is there a run-time requirement for a MTA by default? I thought this is exactly why we have the 'with_sendmail' option. If no one speaks up, I will drop the default MTA dependency. [1] http://cvs.openpkg.org/chngview?cn=36183 -cs __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: implict and explicit requirements (Was: Re: HEADS UP: Apache 2.2 is coming...)
On Tue, Jul 24, 2007, Christoph Schug wrote: [...] Well, another question regarding both PHP packages, 'php' and 'apache-php'. Why is there a run-time requirement for a MTA by default? I thought this is exactly why we have the 'with_sendmail' option. If no one speaks up, I will drop the default MTA dependency. I now dropped it as I cannot remember why it was there. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
implict and explicit requirements (Was: Re: HEADS UP: Apache 2.2 is coming...)
The topic is about how to handle with_foo for a with_foo_bar option that only makes sense in concert with with_foo. On Tue, Jul 10, 2007, Christoph Schug wrote: For me, it looks more like the second [implicit] case, but I might be wrong. If not, there should be some fiddling in the fixing implicit extension dependencies and correlations section, right? I remember the implicit dependency issue but wasn't sure what the best practice is to make clear to the user that with_imap_annotate implies with_imap. My ideas were: - use if with_foo || with_foo_bar in the with_foo logic this will build with_foo if only with_foo_bar is given but rpm -qi will show up with_foo=no. Bad - implicitly set with_foo=yes when the user chooses with_foo_bar AFAIK the current practice. Build and query ok, but somewhat magic. - make the package require itself, enforcing an explicit setting Something like if with_foo_bar then require self::with_foo=yes If the latter works, I'd prefer it. Never tested it. -- http://thomas.lotterer.net __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: implict and explicit requirements (Was: Re: HEADS UP: Apache 2.2 is coming...)
On Wed, Jul 11, 2007, Thomas Lotterer wrote: The topic is about how to handle with_foo for a with_foo_bar option that only makes sense in concert with with_foo. On Tue, Jul 10, 2007, Christoph Schug wrote: For me, it looks more like the second [implicit] case, but I might be wrong. If not, there should be some fiddling in the fixing implicit extension dependencies and correlations section, right? I remember the implicit dependency issue but wasn't sure what the best practice is to make clear to the user that with_imap_annotate implies with_imap. My ideas were: - use if with_foo || with_foo_bar in the with_foo logic this will build with_foo if only with_foo_bar is given but rpm -qi will show up with_foo=no. Bad - implicitly set with_foo=yes when the user chooses with_foo_bar AFAIK the current practice. Build and query ok, but somewhat magic. - make the package require itself, enforcing an explicit setting Something like if with_foo_bar then require self::with_foo=yes If the latter works, I'd prefer it. Never tested it. As I think RPM will not allow the latter, just use the second one. This is what we already have in a bunch of similar packages. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: HEADS UP: Apache 2.2 is coming...
On Tue, Jul 10, 2007, Christoph Schug wrote: On Fri, Jun 22, 2007, Ralf S. Engelschall wrote: On Fri, Jun 22, 2007, Ralf S. Engelschall wrote: Just a heads up: we recently investigated a lot into the packaging of Apache 2.2 in OpenPKG-CURRENT. Now it seems to be time to _finally_ switch the apache package from Apache 1.3 to Apache 2.2. The apache2-xxx packages will become apache-xxx, too. Once I've got APR cleaned up and extended today and Apache 2.2 building just fine again against the external apr package, I'll do the migrations. OpenPKG-CURRENT is now finally upgraded. When you upgrade your instances, please notice that manual intervention is required as mod_php and mod_perl are now in their own packages apache-php and apache-perl. So, previously you installed a PHP/Perl-aware Apache with e.g. openpkg builld -D with_mod_php -D with_mod_php_xml -D with_mod_perl apache | sh while now you have to use openpkg builld-D apache-php::with_xml apache apache-php apache-perl | sh. If been playing around with the new apache packages lately. Here's my list of annotations :-) Apache's default config references several snakeoil SSL certs which aren't supplied by the package leaving Apache in an unusable state. As there doesn't seem to be a helpful script at hand like mod_ssl's mkcert.sh there a several routes to go. The obvious is to steal mkcert.sh from mod_ssl and incorporate it into the apache package. OTOH there might be other packages which could benefit from a general purpose (dummy) cert facility as well. As openssl is part of the bootstrap might it be a better idea to provide such a facility as part of the openpkg package? I don't think this really has to be provided already by the boostrap (openpkg) package. But a dedicated openpkg-x509 package might be more than just reasonable. All packages which require an X.509 certificate should use this to generate one -- both snake-oil, self-signed and real ones, of course. Next topic: apache-php. I haven't played with every single option but there's one I found a little bit curious in the spec file. As I haven't any application which makes use of that specific functionality I want to raise the issue here on the list. apache-php provides an option called 'with_imap_annotate'. It's unclear to me whether this in an independent option or it's just a variant of 'with_imap'. For me, it looks more like the second case, but I might be wrong. If not, there should be some fiddling in the fixing implicit extension dependencies and correlations section, right? Perhaps this is from the Kolab changes? Thomas? [...] Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: HEADS UP: Apache 2.2 is coming...
On Mon, Jun 25, 2007, Torsten Homeyer wrote: Nice, but . I can't tell for the others but, I'm missing an apache1 package. Regards, Torsten I don't see many valid points left nowadays in having an Apache 1.3 despite the fact that maintenance of many packages using Apache will become pure nightmare. Surely not all modules which were part of the apache-1.3.x package are being ported to new apache-* DSO style packages. Furthermore some additional packages which make use of Apache, cacti comes to my mind for example, are not adjusted yet to the new model but I think this is the work we should start to concentrate at. While Apache 2.0 was pretty crap IMHO, Apache 2.2 seems to be quite mature technology. Not to forget that many modules for Apache 1.3 have no almost active development anymore (e.g. mod_perl 1.x) or lack a significat set of features which are available in there Apache 2.2 counterparts (e.g. mod_proxy). So could you please sum up what we are missing at this point? -cs __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: HEADS UP: Apache 2.2 is coming...
On Fri, Jun 22, 2007, Ralf S. Engelschall wrote: On Fri, Jun 22, 2007, Ralf S. Engelschall wrote: Just a heads up: we recently investigated a lot into the packaging of Apache 2.2 in OpenPKG-CURRENT. Now it seems to be time to _finally_ switch the apache package from Apache 1.3 to Apache 2.2. The apache2-xxx packages will become apache-xxx, too. Once I've got APR cleaned up and extended today and Apache 2.2 building just fine again against the external apr package, I'll do the migrations. OpenPKG-CURRENT is now finally upgraded. When you upgrade your instances, please notice that manual intervention is required as mod_php and mod_perl are now in their own packages apache-php and apache-perl. So, previously you installed a PHP/Perl-aware Apache with e.g. openpkg builld -D with_mod_php -D with_mod_php_xml -D with_mod_perl apache | sh while now you have to use openpkg builld-D apache-php::with_xml apache apache-php apache-perl | sh. Experience shows that Apache 1.3 seems to have had some sort of a security bug: access was granted to RewriteRule-mapped directories without actually requiring one to explicitly enable access to this diretcory (area). Apache 2 now handles the access control correctly, but unfortunately this means that one three sites I now already had to add a bunch of missing config directives to re-enable access. So, in case you hit the same problem, just remember that it worked in Apache 1.3 -- but IMHO more because of a bug. Apache 2 is correct here, so you have to explicitly enable access. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: HEADS UP: Apache 2.2 is coming...
On Fri, Jun 22, 2007, Ralf S. Engelschall wrote: Just a heads up: we recently investigated a lot into the packaging of Apache 2.2 in OpenPKG-CURRENT. Now it seems to be time to _finally_ switch the apache package from Apache 1.3 to Apache 2.2. The apache2-xxx packages will become apache-xxx, too. Once I've got APR cleaned up and extended today and Apache 2.2 building just fine again against the external apr package, I'll do the migrations. OpenPKG-CURRENT is now finally upgraded. When you upgrade your instances, please notice that manual intervention is required as mod_php and mod_perl are now in their own packages apache-php and apache-perl. So, previously you installed a PHP/Perl-aware Apache with e.g. openpkg builld -D with_mod_php -D with_mod_php_xml -D with_mod_perl apache | sh while now you have to use openpkg builld-D apache-php::with_xml apache apache-php apache-perl | sh. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenPKG http://openpkg.org Developer Communication List openpkg-dev@openpkg.org
