>> Q: "Would it be possible to recompile just to replace /var/perf/pm with /opt/ibm/pm? "
>> A: Although technically possible, it might raise questions on the viability of PM-Ubuntu project:
>>    1) For a FHS-compliant system, it is supposed to store "static" things only in /opt which may then be mounted for read only;

> If this is truly an issue for you ...

No, I don't mind at all. It is merely an issue for FHS which requires that only static stuff may be stored in /opt.

> storing files in the proper paths in /usr/lib, and keeping just the very few binaries
> that are expected to ever be run by users in /usr/bin, is quite acceptable

The thing is, IBM has PMLinux, ESA(Electronic Service Agent), RSCT(Reliable Scalable Cluster Technology) ... As I knew:
ESA's traditional home is at /opt/ibm/esa/, and
RSCT team has been struggling to move away from /usr/sbin/rsct/ for FHS compliance on Ubuntu.

I hope RSCT's home to be decided at /opt/ibm/rsct/, then many IBM optional packages may stay closely.

> The only thing that is being objected to is the use of paths in /var/perf; which isn't FHS-compliant.
> As I've expressed before, it is a requirement for packages in the archive to follow Debian and Ubuntu packaging policies.

That is fine and we shall comply with. What we keep asking is only to reserve that old address as a relocation sign for some moments.

>> 2) There will be awful consequences to move home for PM (for IBM i, AIX, Linux, KVM ...) after we released the product more than a decade.
> Why?

Worry of big trouble in cross-platform customer support

> On the contrary, this is why I am asking whether you can recompile these binaries.
> To know where to find their files, these programs must have it hard-coded somewhere. This means this value can be changed.

Technically, we just need to add an extra path in the list for configuration search. This is not a big deal in code/document revision.
The major issue remains in cross-platform technical support.

> I thought I had mentioned it in the previous comment, but maybe I forgot: there's an additional issue
> with keeping manual pages in /usr/share/man if the rest is shipped in /opt. Packages shipping things
> in /opt should ship *everything* in /opt, not pick and choose.

This "everything in" condition in FHS standard is certainly ridiculous:
First of all, Ubuntu itself has not yet complied with it: "man" does not look into /opt/man/ with current
/etc/manpath.config, while /opt/bin/ is not included in $PATH by default.

Secondly, we have evidences from PMLinux to feel it bad:
  1) when we have intimate files (like .cfg & .help) and naturally want to keep them at local,
     FHS forces to separate them far away;
  2) when we cooperatively distribute something (like PMUbuntu.8.gz) to a place acknowledged
     for system wide utilities (such as "man"), FHS still says no and we shall have to move them back to private.

> While I agree I've given you both options, it seems as though with all the coming data, it is likely
> best to ship ibmpmlinux files in proper /usr tree instead, such as in the initial packaging I provided
> for review in the bug (which was still affected by the binaries' requirement for arbitrary paths).

There are some problems:
1) PMLinux is NOT a lib, and looks weird to exist in /usr/lib;
2) IBM ESA has been at /opt/ibm/esa/. It's good for PMLinux to be together with ESA who,  among other things,
   services PMLinux's data transmission to IBM.

By the way, have you found why lintian complained PMLinux at /opt/ibm/pm/ ? (I sent you the tar balls on Sep 17 by email)