httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: svn commit: r1294380 - in /httpd/httpd/branches/2.2.x: build/aix/ build/aix/README build/aix/aixinfo build/aix/buildaix.ksh build/aix/mkinstallp.ksh config.layout
Date Tue, 28 Feb 2012 21:26:39 GMT
On Tue, Feb 28, 2012 at 3:06 PM, Graham Leggett <> wrote:
> On 28 Feb 2012, at 3:48 PM, Jeff Trawick wrote:
>> Is this really ready?  The trunk version (if even tested on trunk) at
>> best barely works, and this hasn't seen many eyes.
> I don't have access to an AIX machine, so can only rely on Michael's judgement for this.
Given that we aren't awash with AIX expertise, we need to put some trust in the person doing
the packaging, the same as we do for Netware and other similar platforms.

FWLIW, others on the list have access.

>> Has the packaging of dependent libraries been figured out?  Is there
>> really a such thing as  "ASF.apu.rte and ASF.apr.rte filesets"?
>> Is it appropriate that a package built by a random user is labeled as
>> an "ASF" package, as if the ASF created it?
> I don't see why labeling it "ASF" is a problem. Anyone building the package would be
doing so by following a formal procedure codified in the build script, which is in turn published
by the ASF, as opposed some vendor's build script.

Maybe this info would help...  I dunno.  This really is project-only
scope we're managing, not ASF-wide scope.  Either there is
coordination among different projects, or it shouldn't look like there

>> Is it appropriate to instruct users that in some cases they should
>> "add symbolic links from /usr/include to /opt/include"?
> It looks like zlib isn't necessarily available as a proper package. Given we don't ship
zlib, but depend on it, if the platform has certain limitations regarding the availability
of certain dependencies, we would need to work around that.

It doesn't sound like the right technical solution to me.  CPPFLAGS?

>> What about the todos regarding copyrights and licenses?
> What specifically about them?

The todo file you committed says that verbatim ;)  What are they, and
why can't they be resolved before committing?

> From what I can see, AIX packages offer the option to force the end user to accept a
license before installing a package, and there is an open question as to whether we do this
or not. We don't do it for RPM (nor does RPM let you do this), I see no reason to mandate
doing it here.

License acceptance is one thing.  I dunno what the copyright issue is.

>> What about the trivial issue of hard-coding the version?  (search for
>> "2.2.22")  Presumably the real version is figured out later, but why
>> is this in there?
> A mistake perhaps?
> Looks like VERSION is defined twice, once hard coded, and then a second time properly.
Solution seems to be to remove the first attempt to set VERSION.
>> Committing to trunk is one thing, but IMO before moving to stable
>> branches, especially 2.2.x, this needs careful review by at minimum
>> someone who is very familiar with AIX and will test it personally, and
>> hopefully by others who will ask the necessary questions to understand
>> the ramifications, and not end up having to repair the thing in
>> 2.2.(n+5)/2.4.(n+5) and break compatibility with previous versions.
>> Hats off to Michael for working on this, but this contains a lot of
>> gory details to consider, and AFAIK no one who has logged onto an AIX
>> box since mid-2008 has stared at it enough to identify even the most
>> trivial of issues.
> The build for v2.2.x will look nothing like the build for v2.4.x, and for this reason
there is no way to apply changes to trunk, and then backport it, as each branch works completely
differently, and therefore the build will work completely differently.
> If this is too much of a pain, working from a branch might be a better idea until these
issues are solved.
> Regards,
> Graham
> --

Born in Roswell... married an alien...

View raw message