https://bugzilla.redhat.com/show_bug.cgi?id=1816301
--- Comment #17 from mark.olesen(a)esi-group.com ---
Sorry about taking longer to get back to you, caught up in other build issues.
(In reply to david08741 from comment #16)
Why would put them in /usr/lib/openfoam, rather then in /usr/lib/?
That would be much nicer, imho, as if you only have one openfoam, it is not
unnecessarily one level deeper.
There are a few issues with putting everything into /usr/bin and /usr/lib
directly.
We have a forest of around 160 libraries and another 300 binaries that most
people don't appreciate having dumped into regular locations
(cf,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918112)
Another vital thing is that we want to support installation of different
versions at the same time. This is fairly common in an engineering environment.
Someone might need to use openfoam1812 until their current vehicle goes into
production, but use openfoam1912 for newer projects. Or just as importantly,
might wish to verify how some particular result may be change between versions.
Besides that, you MUST not install in /usr/lib. Header files need to
go to
%{_includedir}/openfoamVER, libs go to %{_libdir}/openfoamVER etc.
See [1] for the specific directories.
This doesn't work very well at all with OpenFOAM. For good or bad, we have a
large number of headers and templated code spread across many directories. The
homegrown wmake (wrapped make) system creates a web of symlinks for the
headers, templates. If we start relocating these out of the source context, we
need to rewrite a substantial amount of the wmake system to accommodate this
and introduce loads of problems.
If you want to put them in openfoam/openfoamVER/ rather then
directly
openfoamVER, then there are two options, create a package
openfoam-filesystyem that owns the shared openfoam/ directories.
The other one is co-owning, as you mentioned. See [2] for more on directory
ownership.
An openfoam-filesystem owner package sounds OK. But would prefer to get most of
the current package on its way first. Otherwise I fear that we will near leave
the starting blocks.
/mark
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component