Re: resolving Apache::Test vs. Apache::test collision
Geoffrey Young wrote: So it seems to me that the simplest route to take is to s/Apache::Test/Apache::Tester/ as suggested by David. Only one file is modified. If there are no objections, I'll proceed with this route. not to be nitpicky, but Apache::Tester strikes me as, well, something. this is a really cool piece of software that has the potential to make many, many developer's lives easier - having a descriptive, decent name is probably important. (though getting everyone to agree may be difficult ;) how about Apache::TestHarness or Apache::TestSuite or something similar? We already have the Apache::TestHarness module. But I see no problem moving the $VERSION control into that module and release it as Apache-TestHarness, and rename the Apache::Test module to a different name. speaking of which, despite CPAN's general dislike of multi-level naming schemes, would Apache::Test::Harness make life easier? technically, we could keep everything other than Test.pm as is, avoid namespace collisions, and still refer to the whole thing (colloquially) as Apache::Test. ok, well it's just an idea... That won't work well, because if the distro is named Apache-Test, people will try to install Apache::Test via CPAN. or search for it in search.cpan.org. Also I don't get what good the multi-level naming will do to the resolving this problem. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Randy Kobes wrote: On Thu, 8 May 2003, Stas Bekman wrote: The problem with providing a replacement for Apache::test is that some people are going to reinstall older mod_perl versions and kill the overriden file. That's certainly true in general (for case-preserving but otherwise case-insensitive file systems) - I just thought I'd clarify why this problem never really arose before on ActivePerl Win32. There, mod_perl 1 works with perl-5.6.1 but not with perl-5.8.0 (due to large files support), and mod_perl 2 works with perl-5.8.0, but not (practically speaking) with perl-5.6.1. So it's very rare that Apache::test and Apache::Test would get installed within the same Perl tree, at least while these two were tied to particular mod_perl versions. Cool. What about MacOSX? Any other systems? The other issue is that we have to ship and install Test.pm and test.pm, because mp1 users will need test.pm on case-sensitive systems. On case insensitive systems only one of these will be installed (the other will overwrite the first one). __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: resolving Apache::Test vs. Apache::test collision
Randy Kobes wrote: On Thu, 8 May 2003, Stas Bekman wrote: [ .. ] One question remains: should the package be renamed to Apache-Tester as well? Since people will see Apache::Test and will try to install Apache::Test in CPAN.pm, and that won't work. Probably to make a clean break the whole package should be renamed. And also, probably the current Apache-Test packages on CPAN should be deleted, as Apache::Test would still show up in the CPAN indices, under older Apache-Test packages (eg, there's some obsolete modules in older versions of libwww-perl that can be seen within CPAN.pm). I think though that the Apache::Test module would still remain in the indices after such deletion, and CPAN.pm would direct queries to the module owner. You'll probably have to contact modules@perl.org to get the module itself removed from the indices. Yes, that shouldn't be a problem. So currently we are down to two options: 1) Integrate test.pm in Test.pm. I think we should bundle Apache::Test with future versions of mod_perl to make the maintenance simple and remove the original Apache::test from it. 2) Rename Apache::Test to Apache::Tester (or else) to resolve the collision. Rename the distro Apache-Test to Apache-TestHarness (or else) to avoid confusion. Looks like if we can provide a clean implementation of (1) that's would be the best solution. Randy says that it shouldn't be a problem with winFU. If David says that it's cool with MacOSX, let's try to take this route then. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
specweb99
Hi, I have a question about the state of specweb99 module. The reason is that I failed to compile the source I pulled out of CVS on RedHat 7.3 Linux: apxs -c -DLINUX -I../../mm-1.1.3 -L../../mm-1.1.3 -lmm mod_specweb99.c gcc -DLINUX=22 -DMOD_SSL=208105 -DUSE_HSREGEX -DEAPI -DEAPI_MM -fpic -DSHARED_MODULE -I/usr/local/apache/include -I../../mm-1.1.3 -DLINUX -c mod_specweb99.c mod_specweb99.c: In function `checkUPFile': mod_specweb99.c:355: invalid operands to binary == mod_specweb99.c:442: incompatible types in assignment mod_specweb99.c: In function `checkCADFile': mod_specweb99.c:476: invalid operands to binary == mod_specweb99.c:569: incompatible types in assignment apxs:Break: Command failed with rc=1 make: *** [mod_specweb99.so] Error 1 I traced the macros a bit and it seems there Solaris and Linux defs are mixed up. Am I right? TIA, -a
Re: resolving Apache::Test vs. Apache::test collision
So currently we are down to two options: 1) Integrate test.pm in Test.pm. I think we should bundle Apache::Test with future versions of mod_perl to make the maintenance simple and remove the original Apache::test from it. if you mean future versions of mp1, that's a good idea. that's probably reason enough to release 1.28 when we get this all sorted out. 2) Rename Apache::Test to Apache::Tester (or else) to resolve the collision. Rename the distro Apache-Test to Apache-TestHarness (or else) to avoid confusion. actually, I hadn't thought about it much, so I didn't realize that we could keep Apache-Test as the distribution name while changing the offending file (*duh*). sticking with Apache-Test as the distribution gets my vote. I don't think it's too confusing - other major distributions use packages that differ from the distribution name (libwww-perl, perl-ldap, Filter, etc). now I care much less about the name of the package that actually supplies the base functions - Apache::Tester is fine with me. Apache::TestPlan also sorta makes sense, since then use Apache::TestPlan; use Apache::TestRequest; mirror what's really happening - one package is required for planning (and other housekeeping functions) and one is required for issuing the requests. I dunno, I'm terrible with names anyway, so I'll shut up now and just wait for the results :) --Geoff
Re: specweb99
[EMAIL PROTECTED] wrote: I have a question about the state of specweb99 module. The reason is that I failed to compile the source I pulled out of CVS on RedHat 7.3 Linux: apxs -c -DLINUX -I../../mm-1.1.3 -L../../mm-1.1.3 -lmm mod_specweb99.c gcc -DLINUX=22 -DMOD_SSL=208105 -DUSE_HSREGEX -DEAPI -DEAPI_MM -fpic -DSHARED_MODULE -I/usr/local/apache/include -I../../mm-1.1.3 -DLINUX -c I'm assuming you are using the Apache 1.3 version? Most of the folks currently using mod_specweb99 are on Apache 2.0, so I don't know what kind of shape the 1.3 version is in. Patches (created with diff -u) would be appreciated. Correct. I need it for HP's VirtualVault which is based on 1.3. For 2.0, we don't use apxs to build mod_specweb99, although that is a worthy goal. We build it as if it were part of the standard httpd distribution. Copy the files from the specweb99-2.0/ directory to your httpd-2.0/modules/generators/ directory, re-run ./buildconf, then configure with --enable-specweb99. So, it wasn't at all built agains 1.3 (despite the specweb99-1.3)? -a Greg
Re: specweb99
[EMAIL PROTECTED] wrote: I'm assuming you are using the Apache 1.3 version? Most of the folks currently using mod_specweb99 are on Apache 2.0, so I don't know what kind of shape the 1.3 version is in. Patches (created with diff -u) would be appreciated. Correct. I need it for HP's VirtualVault which is based on 1.3. For 2.0, we don't use apxs to build mod_specweb99, So, it wasn't at all built agains 1.3 (despite the specweb99-1.3)? It was _only_ built against 1.3 at one time, before it went into the apache.org CVS. But I can't tell you which platforms it works/doesn't work on for 1.3 at present, since most of the users are on 2.0 now. Again, patches are welcome. Greg
