[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[RFC] Debian skin for AIX



[With apologies for the cross-posting, but I think that in this case it is
warranted]
Hi,

	I have been working on a port of dpkg to AIX and have come across
some issues which need resolving. This email will attempt to document my
various thoughts on the matter in the hope that a useful discussion will
result on how to solve these problems.

Facts :

1.  AIX system administration tools can sometimes have serious failures if
the GNU tools are in the PATH for root ahead of the AIX supplied version
of such utilities.
2.  AIX versions of common utilities are sometimes feature-wise braindead
(AIX make is a prime example) or differ in subtle ways from the GNU
versions of the utilities - different enough to cause build problems.

The problems arising from the above two facts are :

a.  The GNU utilities cannot replace the AIX utilities in all cases as
root would need the AIX version of the utilities. Thus the two versions
would have to co-exist on the same system. The AIX toolbox distributed by
IBM has solved this problem by placing the files under /usr/linux wherever
a Redhat Linux install would place the file under /usr . For Debian,
/etc/alternatives would have to know about this. Would the change in paths
conflict with anything in Debian policy?

b.  The AIX package database is called  the ODM (sorry - you'll have to
ask someone who knows, what it stands for) and contains details of files
installed via the AIX installer. The dpkg database needs to be able to
read that information and be capable of accepting AIX programs as
an alternative to dependencies. For example, PERL is distributed as part
of AIX proper and also as part of the toolbox. If there is a Debian
package that depends on PERL, and if the AIX PERL is installed, then the
Debian installer needs to recognize that the dependancy has been met.

Build and bootstrap issues :

a.  In order to make the port useful, one would have to package up the
dpkg tools into an AIX package that the native installer can install. Is
this something that could be placed on the Debian site?

b.  Some of the dpkg tools depend on the output from gcc and the gcc that
I am using is the one available via the AIX toolbox (which is built by
Cygnus / Redhat for IBM). I've already noted some AIX-isms from the gcc
output (for example - the output of 'gcc --print-libgcc-file-name') but am
not sure whether this these are Redhat-isms - in which case a Debian port
of gcc to AIX might be required before dpkg in order to make things
"right".

c.  Since I dont have access to an ia64 system, I cant tell if the port
will have problems running under 64-bit AIX. 

d.  The AIX port of GNUpg (needed for signing a package) is on rather
shaky grounds. The build that I did of this program so that I could
excercise dpkg functions, complains that I am 'using insecure memory' -
whatever that means. The program appears to work, but given that I am not
a security expert, I cant tell if it is working to spec.

e.  Before IBM started distributing the AIX toolbox, the main source of
GNU utilities for AIX used to be the Bull site. These packages install
themselves in /usr/local and work fine but I consider the IBM packages to
be of superior quality and am using these packages for the bootstrapping.
People who do not have root access on their AIX systems and who wish to
contribute to the port may have problems if their system administrator
prefers the Bull packages.....

Program feature problems :

a.  Tools like 'sudo' (which is needed to use dpkg-buildpackage) dont
understand DCE authentication. This restricts the type of userid a builder
could use on an AIX system. Havent tried building 'fakeroot' yet....

	Comments, concerns, advise are welcome.

Jor-el



Reply to: