On Tue, 2006-24-10 at 10:26 -0400, Ben Konrath wrote:
On Tue, 2006-10-24 at 07:40 +0100, Andrew Haley wrote:
> Ben Konrath writes:
> > Hi Andrew,
> >
> > Last week I started looking into making our eclipse packages mulitlib
> > compatible to solve bug # 207016 and I thought I'd write up a little
> > status report of what I found.
> >
> > Here are the issues we need sort out:
> >
> > 1) Ensure the src zips are the same for all arches
> > 2) Put the native fragments in %{_libdir} - the swt classes need to go
> > there too because they use 32-bit or 64-bit references depending on
> > the arch
>
> So you're going to put swt.jar into %{_libdir} ? Ewww. No, I don't
> have any better idea. :-)
Sorry, I meant %{_libdir}/eclipse/. I know it doesn't exactly fit but
I'm open to suggestions.
If I'm reading [1] correctly, I think our thinking that the
arch-specific stuff should all go in /usr/lib/eclipse is correct:
/usr/lib : Libraries for programming and packages
Purpose /usr/lib includes object files, libraries, and internal
binaries that are not intended to be executed directly by users or
shell scripts. [22]
Applications may use a single subdirectory under /usr/lib. If an
application uses a subdirectory, all architecture-dependent data
exclusively used by the application must be placed within that
subdirectory.
[22] Miscellaneous architecture-independent application-specific static
files and subdirectories must be placed in /usr/share.
and under the /usr/share/section:
Any program or package which contains or requires data that doesn't
need to be modified should store that data in /usr/share
(or /usr/local/share, if installed locally). It is recommended that a
subdirectory be used in /usr/share for this purpose.
Andrew
[1]
http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY