Hi spot!
On Mon, 2006-06-12 at 18:23 -0500, Tom 'spot' Callaway wrote:
> 1. Redefining libdir for mono packages:
>
> If mono and its tools cannot find a library on a 64bit architecture
> when
> it lives in %{_libdir} (/usr/lib64), then mono is fundamentally broken
> on that architecture, and needs to be fixed.
I agree.
> 2. Putting DLLs in %{_datadir} vs %{_libdir}:
>
> The FHS says that /usr/share (aka, %{_datadir}) is for "Architecture
> Independent Data". These DLL files do not seem to qualify as
> "Architecture Independent Data". I think that having them live in the:
> %{_libdir}/mono/ hierarchy seems to be the most appropriate for them
> at
> this point in time. Obviously, this can be revisited if upstream
> changes
> the default location. The gacutil command should be putting these DLL
> files in the right place.
>
My understanding is .dlls and .exes are architecture independent.
Should they end up in %{_libdir} or always end up in /usr/lib? Fedora's
Python and Perl place arch independent data into /usr/lib, (I assume so
that they can be noarch) should mono as well? All the *-sharp packages
on my system currently follow this convention but beagle, tomboy, and
banshee end up in %{_libdir}. Perhaps relevantly, these three are
primarily applications but they do supply .dlls.
I have only one package on my system that installs something
into /usr/lib(!mono):
gtk-sharp2 => /usr/lib/gtk-sharp-2.0/gconfsharp-schemagen.exe.
By contrast the beagle/tomboy/banshee triumvirate install to
%{_libdir}/[PKGNAME]
Should this be allowed by the guidelines or should all mono packages go
under /usr/lib/mono (similar to the python and perl hierarchies
in /usr/lib)
The above examples illustrate that applications and libraries are
currently defaulting to different areas. Does it make sense to put
applications in a different area than libraries? Python and Perl seem
to use /usr/lib for arch independent libraries, %{_libdir} for arch
dependent libraries, and %{_datadir}/[PKGNAME] for arch-independent
program-specific scripts. (ex: rpmlint). There is one mono application
under review (nant) that places its files in %{_datadir)/[PKGNAME]. Do
we need to move this or is it fine as is?
If we separate applications and libraries, how do we determine
which .dlls belong in an application directory and which belong in a
library directory? ELF shared libraries have ldconfig as a tipoff. I
can think of the following tipoffs for a mono library, are there others?
The .dll is listed in a pkgconfig .pc file.
The package attempts to setup the .dll in the GAC. (What are the
telltales of this?)
Forcing everything to /usr/lib/mono would be the easiest to review but
would cause a lot of hard to justify changing of upstream's install
locations. OTOH, the hodgepodge of locations we have now is not
conducive to good reviewing because it leaves all these ambiguous areas.
Where do you see the logical lines falling?
> 3. Forcing local copies of DLL libraries instead of using system
> installed DLLs.
> This concept is documented upstream here:
> http://www.mono-project.com/Assemblies_and_the_GAC#Libraries_with_Unstable_APIs
> IMHO, this is a really stupid and braindead idea. In fact, I've yet to
> talk to anyone who actually thinks this is a good idea. This is the
> same
> thing as static linking a private copy of a library instead of using
> the
> system shared lib. We do NOT permit this sort of behavior in Fedora,
> and
> mono is no exception.
Here here!
What are the easy ways to detect this issue?
1) Upstream tarball contains .dlls that were not rebuilt from source
contained in the package.
2) Look through the installed .dlls for any that have the same name as
system .dlls or are suspiciously out of place (Package is myDiary and
contains mysql.dll, sqlite.dll, and gtk-sharp.dll)
3) Source directories look odd:
PKGNAME/
src/
data/
libs/
gtk-sharp/
atk-sharp/
Anything else?
-Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
