On Tue, Feb 28, 2012 at 10:26 PM, Jeff Trawick <[email protected]> wrote:
> On Tue, Feb 28, 2012 at 3:06 PM, Graham Leggett <[email protected]> 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. > I cannot answer this. ASFhttpd may be the better (though ugly imho) PKG name. > > > http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.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"? > > > Note: I test for a script named build/aix/aixlinks that would be used to create symbolic links where/if needed. AIX has not used /opt as /usr/local - it has used /opt/freeware instead - I debated between using /opt/include, /opt/lib, etc and /opt/aixtools/* - I decided /opt/* was better for more generic things, and /opt/httpd/lib, /opt/httpd/include for things needed and might collide with /usr/lib symbolic links. installp has a mechanism for when two filesets want to own the same file. I wish I knew the intricacies, but there are ways to manage this - might even be in just checking if the links are already there or not. re: zlib - the library is installed on AIX by default. The zlib include files are not, but httpd is not dependent on the include file to run (I hope) - I don't have it on the system I am testing the installp with. re: expat: using the embedded I think, I know I was - will have to verify and/or I have an extra pre_i check I need to perform. In any case, it is easy enough to test for presence of /usr/lib/libz.a in a pre_i check. My question is: what else? > 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? > CPPFLAGS? A typo of mine, or an AIX document referencing something not valid for right now. > > > > >> 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. > The copyright message is a banner that is shown during the install process. It is something "nice". I sometimes go a bit too extreme in finishing things. I guess the file I could use for that is NOTICE. That comes very close The license is installed in /usr/swlag/en_US/${PKG}.${NAME}.la - which follows AIX nomenclature. The acceptance is implied because I have not figured out how to enforce acceptance (either answering the question, setting an environment variable ACCEPT_LICENSES=yes, or using a flag -Y to installp. > > > >> 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? > Say mistake, not supposed to be hard-coded anywhere anymore (ouch). Laziness. > > > > 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. > The hard part: mkinstallp.ksh is the same for all - only /usr/local/* is banned by the script - especially since mkinstallp (the AIX one from 5.3 at least - seems to leave some temporary files behind there, and when I reused the DESTDIR area had install failures because of it. I am trying to be rigorous in not using /usr/local/* for anything as AIX basically adopted /opt (my opinion) when they started "Linux affinity". Back on topic: the only area that need changes between branches - might be aixinfo (which uses commands borrowed from pkginfo to extract versioning numbers) and buildaix.ksh which has a "default" configure command. The option B is to run configure yourself - if Makefile exists, configure is not run - only a message that it is not being run and a listing of the config.* files and Makefile (to see date they were made). > > > 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... >
