>> 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)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1448092
Title:
[needs-packaging] ibmpmlinux
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/1448092/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
