Hi,
> Now, my understanding is that mono uses these DLL files as libraries,
> the EXE files as binaries. Are they compiled from source, or provided as
> is for use? If they're not compiled from source, this seems like a
> violation of Fedora policies (no binary only bits, please).
From what I've packaged, everything is source built.
> Presuming that they are compiled from source, they should be
> architecture specific. I did not think that C# was an interpreted
> language like python/perl... is it more like Java (runtime)?
Yes.
> > 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?
>
> Well, there are several questions there:
>
> 1. Are the DLLs and EXEs truly architecture independent?
No. I have code which identifies itself as 64 bit and 32 bit.
> 2. Are the EXEs used like binaries? (They certainly seem to be)
Yes. The are effectively binaries.
> 3. How much will these mono apps break if we move the EXE location to
> %{_bindir}? (In my tests with tomboy, it seems to work fine if i move
> the EXE to %{_bindir} and edit the /usr/bin/tomboy wrapper script)
It depends on the app. monodevelop hates being moved.
> 4. How much will mono (and its app) go nuts if we move the DLLs to
> to /usr/share ?
A lot - unless you specify to look somewhere, the likes of MD goes
bizerk.
> 4. How much will upstream (and unpackaged mono apps built from source)
> go nuts if we move our packaged mono bits out of the fake /usr/lib tree?
That's less of a problem IMO. I don't see them going loopy over the
Debian or Mandriva bods.
> > If we separate applications and libraries, how do we determine
> > which .dlls belong in an application directory and which belong in a
> > library directory?
>
> I'm hoping this is as clear cut as "DLL == library, EXE == binary".
Speaking with some of my mates on the darkside over the last couple of
days, they refer to the exe as binaries and dlls as libs. Okay, that
could just be for ease of conversation...
> > What are the easy ways to detect this issue?
>
> Man, I really don't think there are easy ways to detect this. Is a
> package including a DLL file that exists in another package?
Quite probably, yes.
> > 1) Upstream tarball contains .dlls that were not rebuilt from source
> > contained in the package.
>
> Yeah, thats a huge freaking no-no. That alone should invalidate the
> package for Fedora inclusion.
Sometimes though they have to do that to build the binary which then
rebuilds the source (sort of chicken and egg)
> Mmmm, this gives a new meaning to DLL hell. Thoughts?
Welcome to the wonderful world of Microsoft lads.
Seriously, this is one of the problems of .NET that people scream about
on Win32 platforms and there doesn't seem to be anything that can be
done as the code has to work in exactly the same way irrespective of
platform (the CIL does the grunt work). Upshot, they have to have the
directory structure they have - the app looks in a particular directory
to try and find the dll, but there is nothing in the system that says
look in the common area.
gac is a nice attempt to get around this, but even that is only so far.
TTFN
Paul
--
ich liebe Ashleigh, eins zwei drei
ich liebe Ashleigh, auf meinem Knee zu hüpfen
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
