Summary of the 2009-01-06 Packaging Committee meeting

Wed Jan 7 19:30:36 UTC 2009

Doug Ledford wrote:
> On Wed, 2009-01-07 at 09:20 -0800, Toshio Kuratomi wrote:
>> Doug Ledford wrote:
>>> On Tue, 2009-01-06 at 14:37 -0800, Toshio Kuratomi wrote:
>>>> Doug Ledford wrote:
>>>>> On Tue, 2009-01-06 at 13:16 -0600, Jason L Tibbitts III wrote:
>>>>>> * Make adherence to the FHS a MUST, with the added exception of
>>>>>>   /usr/<target> for cross toolchains.
>>>>> I happen to have a few packages that just *can't* follow FHS (unless we
>>>>> opt to ignore FHS and allow a package to install to /opt, but that's
>>>>> always been just as verbotten by the FHS for the initial software
>>>>> distributor versus an ISV as failing to follow any other FHS specified
>>>>> layout).
>>>>>
>>>> Example SRPMS?  (Or the package name if it's already in cvs).
>>> The main ones are all MPI implementations.  They need per arch and per
>>> version libraries and runtimes.  OpenMPI is in cvs, but hasn't been
>>> updated to my current layout as used in RHEL.  I tried, for about 5
>>> consecutive releases, to adhere to the FHS with that package.  It just
>>> ended up being more problems than could be solved.  The current version
>>> of the package as shipped in RHEL (and there is an example of it in the
>>> Infiniband link in my sig) puts the entire tree under
>>> %{_libdir}/%{name}/%{version}-%{opt_cc}.  While you can *attempt* to get
>>> OpenMPI to work with a FHS standard layout, the two other main MPIs,
>>> mvapich and mvapich2, flat will not work with a FHS layout at all.  They
>>> *must* be installed under a single directory prefix that doesn't
>>> conflict with any other installations.
>>>
>> openmpi doesn't look too bad.  If this was being reviewed with the FHS
>> Guideline in mind, these are the questions I'd ask:
> 
> As mentioned in my original mail, you are looking at the older version
> of OpenMPI in Fedora CVS, where as the version on my people.redhat.com
> page for RHEL is both A) significantly newer and B) has a vastly
> different file layout because the file layout you are seeing in the
> Fedora CVS version of the package proved to be impossible to get
> completely right.
> 
If it's on your people.redhat.com account, could you post a link?  The
index.html you have up doesn't have a link to this package.

> However, even though you are referencing a layout that proved not to be
> effective, I'll address your questions because I think the answers might
> point out why it's so hard to get OpenMPI right:
> 
> 
>> /usr/share/openmpi/1.2.4-gcc/help32/openmpi/doc -- Are the files
>> located
>> here used by the programs at run time?  If so, this is fine.  If not,
>> they should be in /usr/share/doc (marked as %doc) instead.
> 
> Yes, they are used by the runtime.  In particular, ompi_info --all will
> read all the available options for the different modules that OpenMPI
> actually has built.  As the modules that a person builds is build time
> configured, the OpenMPI architecture was set up so that each module
> could just stick its relevant help info in these files, and the run time
> help system will read the files as installed by the various modules.
> 
Cool.  So that's fine.
> 
>> /usr/share/openmpi/1.2.4-gcc/man -- Why are these man pages placed
>> here?
>>  Is it because of conflicts with other mpi implementations?  If so,
>> this
>> is fine but see my question about environment-modules.  (Note, I think
>> you have to manually mark these as %doc since they don't live in the
>> system %{_mandir})
> 
> Yes, they conflict with other MPI installations.

So with environment-modules, this is fine too.

  In my current spec
> file I don't mark them as %doc (you can't as far as I know, because the
> %doc macro includes a step to copy the files into /usr/share/doc and as
> such can't be used on anything *but* doc files), but I did have to
> manually compress them in the %install section because they aren't in
> the system mandir.
> 
This was untrue when I first learned to package but I haven't tested
recently.  If you give a relative path to %doc it copies as you say.  If
you give an absolute path to %doc, it just marks the file as being a doc
file.

> 
>> /usr/share/openmpi/1.2.4-gcc/bin32
>> /usr/share/openmpi/1.2.4-gcc/help32 -- Are these files arch specific?
>> If so (even if they are text files but arch specific), they cannot go
>> in
>> /usr/share.  Somewhere under %{_libdir}/openmpi would be better.
> 
> Yes.  But more than just arch specific, they are openmpi version
> specific and as I pointed out in my original explanation, users often
> need multiple versions of openmpi installed.

Yep, agreed.

>  So, if I were to put the
> binaries in /usr/bin, not only would I have to encode the arch, but also
> the version into the binary name.  This would then need to be aliased
> via something like the alternatives system.

As you found, alternatives is the wrong solution for this.  These are
being used by users who might not be the system admin.

>> %{mode} in directories like /usr/share/openmpi/1.2.4-gcc/bin32 -- if
>> we
>> place these files in %{_libdir}, can we get rid of the %{mode} for
>> them
>> since the information will be present in the %{libdir} path?
> 
> Yes.  This has been done in the latest spec file.
> 
>> /usr/share/openmpi/1.2.4-gcc/bin32/*
>> /usr/lib/openmpi/1.2.4-gcc/openmpi/* -- Do these directories exist
>> because of file Conflicts with other MPI implementations?  If so, this
>> seems basically okay but how are users supposed to access these
>> programs?  How are programs supposed to find the libraries?  Would it
>> be
>> proper to package an enviroment-modules configuration for switching
>> between the implementations?
> 
> Yes, there are file conflicts not only with other MPI implementations,
> but different versions of the same MPI, and also the same MPI compiled
> with different compilers.
> 
> In the current setup, access if via either mpi-selector (a glorified
> alternatives setup that uses paths instead of links to solve the
> problem) as well as environment-modules.  When I bring the current stuff
> over to Fedora, the mpi-selector setup will get dropped and only
> environment-modules selection will be supported.
> 
> The libraries are found via an LD_LIBRARY_PATH setup created by either
> the mpi-selector or environment-modules usage.  The man pages are found
> by placing the mandir and the bindir in the same top level directory.
> In the case that <prefix>/bin/<command-name> has a matching
> <prefix>/man/man?/<command-name>* man page, man automatically finds it
> without having to manipulate the manpath or other settings.
> 

So, with the exception of the arch-specific files in %{_datadir} which
has changed for the new release, this seems to be FHS-kosher to me.  If
you can get me a link to the new package I can take a look and see if
the situation there is worse.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/ca63c12a/attachment.sig>