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. > 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. > 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. > What about the todos regarding copyrights and licenses? What specifically about them? 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. > 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 --
