Hello --

First of all, let me preface this by saying that I am relatively new
to AIX and so there's a good chance I might be doing something
silly/irrational. My problem is that 'lslpp -l' shows two different
versions of X11.base.lib and X11.base.rte installed, and the file
dates match the earlier version. I need to have the *other* version
installed (in order to match a client computer which is having
problems), but this can't work because installp won't let me install
an update which it thinks is already installed. So, my questions are:

1. Why does lslpp show two versions of the same update installed? Is
that normal?

2. How do I reinstall the second version (which it thinks is already
installed) so that I can have the files on this machine match the
client machine's files?

Any help or advice is greatly appreciated.

Thanks!
Andria

Andria Thomas wrote:
>
> Hello --
>
> First of all, let me preface this by saying that I am relatively new
> to AIX and so there's a good chance I might be doing something
> silly/irrational. My problem is that 'lslpp -l' shows two different
> versions of X11.base.lib and X11.base.rte installed, and the file
> dates match the earlier version. I need to have the *other* version
> installed (in order to match a client computer which is having
> problems), but this can't work because installp won't let me install
> an update which it thinks is already installed. So, my questions are:
>
> 1. Why does lslpp show two versions of the same update installed? Is
> that normal?
>
> 2. How do I reinstall the second version (which it thinks is already
> installed) so that I can have the files on this machine match the
> client machine's files?
>
> Any help or advice is greatly appreciated.
>
> Thanks!
> Andria

Look at the 'lslpp -l' output carefully. Some filesets will be
listed multiple times, but only once each under the headings
/etc/objrepos, /usr/lib/objrepos, /usr/share/lib/objrepos.
These correspond to the three divisions of where the fileset
unloads its files (it is not quite that simple, but I don't
want to get to complicated for your question). The X11.base.rte
fileset has both root and usr parts, so it shows up twice in
the 'lslpp -l' output. The lower level will probably appear
under the /etc/objrepos heading and the higher level under
the /usr/lib/objrepos heading. What this means is that the
original (BASE level, e.g. 5.1.0.0) install went into both
categories, but the later (UPDATE, e.g. 5.1.0.35) install image
only updated /usr category files, so that level only shows up
that heading in the lslpp output.

To get a better idea of the complete install history, use:
lslpp -ha X11.base.rte X11.base.lib
The level marked as APPLY with the latest datestamp should
be the level reported by 'lslpp -l'.

Now to your questions:
> the file dates match the earlier version.
Probably not all of them. The later level (e.g. 5.1.0.35)
would be a delta or update image. It only replaced the files
that had changed, not all the files in that fileset, so some
of the files might have the timestamp of the earlier level.

> installp won't let me install an update which
> it thinks is already installed.
The typical solution to back-leveling a fileset is to:
a) Use the force-overwrite option of installp (-F flag)
to put the BASE level (e.g. 5.1.0.0) back on, then
b) Apply the update level that you want (e.g. 5.1.0.20)

> 1. Why does lslpp show two versions of the same update installed?
Yes, depending on the fileset and how you read the lslpp
output, it is common to see a fileset listed multiple times.
See the explanation above about root/usr/share categories.

> 2. How do I reinstall the second version (which it thinks is already
> installed) so that I can have the files on this machine match the
> client machine's files?
Use the force-overwrite option in the smit install panels
(or the -F flag on the installp command line) to put the
base (e.g. 5.1.0.0) level fileset on and then apply the
update to get to level you want to match.

The X11 filesets are not critical, but I usually recommend
making a system backup before doing the force-overwrite,
especially of a bos.* fileset.

Paul Landay