Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of trawick@gmail.com designates
 209.85.212.45 as permitted sender)
Received-SPF: pass (google.com: domain of trawick@gmail.com designates
 10.52.20.78 as permitted sender) client-ip=10.52.20.78;
MIME-Version: 1.0
In-Reply-To: <EC3F4F41-A29C-41F5-9D02-89B6D6B2CC64@sharp.fm>
References: <20120227225719.A87BD2388900@eris.apache.org>
	<CAKUrXK4+UQZ5m7vpz5Lxr=RYwkpobpt7fESwVipvhu0E6cF=Tg@mail.gmail.com>
	<EC3F4F41-A29C-41F5-9D02-89B6D6B2CC64@sharp.fm>
Date: Tue, 28 Feb 2012 16:26:39 -0500
Message-ID: 
 <CAKUrXK4MTMtzFg-yaEtsG3jUPTR-sj7C_FDoMH3cuVqULJuOwg@mail.gmail.com>
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
From: Jeff Trawick <trawick@gmail.com>
To: dev@httpd.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 28, 2012 at 3:06 PM, Graham Leggett <minfrin@sharp.fm> wrote:
> On 28 Feb 2012, at 3:48 PM, Jeff Trawick wrote:
>
>> Is this really ready? =A0The 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 judg=
ement for this. Given that we aren't awash with AIX expertise, we need to p=
ut some trust in the person doing the packaging, the same as we do for Netw=
are and other similar platforms.

FWLIW, others on the list have access.

>> Has the packaging of dependent libraries been figured out? =A0Is there
>> really a such thing as =A0"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 packa=
ge 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 bui=
ld 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.

http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=3D/co=
m.ibm.aix.genprogc/doc/genprogc/pkging_sw4_install.htm

>
>> 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 limitati=
ons regarding the availability of certain dependencies, we would need to wo=
rk 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 quest=
ion as to whether we do this or not. We don't do it for RPM (nor does RPM l=
et 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? =A0(search for
>> "2.2.22") =A0Presumably 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 t=
ime properly. Solution seems to be to remove the first attempt to set VERSI=
ON.
>
>> 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 i=
t, as each branch works completely differently, and therefore the build wil=
l work completely differently.
>
> If this is too much of a pain, working from a branch might be a better id=
ea until these issues are solved.
>
> Regards,
> Graham
> --
>


--=20
Born in Roswell... married an alien...