Changing default paths for mono packages
by Christian Krause
Hi,
After discussing the topic on mono-devel and with the upstream mono
developers I would like to run the following suggestions by the FPC:
The way how mono is packaged in Fedora is uncommon with respect to
mono's default search paths. The standard mono's libdir "/usr/lib" was
changed to "%{_libdir}" (which is "/usr/lib64" on x86_64).
Since this contradicts upstream's understanding of the directory
structure it causes lots of unnecessary work for the maintainers and
quite a couple of bug reports due to uncaught uses of these default
paths within the mono packages. Nearly every mono package must be
adjusted and so the majority of all patches for mono consists solely of
%{_libdir} "fixes". Since it looks like that upstream (not only
mono-core, basically all mono-based packages) does not agree to these
changes, non of these patches are accepted upstream nor do we get any
help from upstream if the issues are caused by Fedora's directory structure.
However, solving this issue (and reverting the change to mono's default
paths) would include to loose the ability to use
32bit parts of the mono stack in x86-64 - a feature which never worked
correctly and is not available for perl or python either.
Fedora's decision to change the default paths was based on a statement
from the mono developers a couple of years ago regarding the
architecture-independence of the mono assemblies. I have discussed this
topic with upstream again, and there was an agreement that
mono assemblies are treated as platform independent and so the original
reason to change the paths is not valid anymore.
Please see all details on the following wiki:
https://fedoraproject.org/wiki/User:Chkr/MonoMultiarchChanges
So my question to the FPC:
Do you agree with the suggested changes?
Best regards,
Christian
13 years
Re: [Fedora-packaging] Changing default paths for mono packages
by Christian Krause
Hi,
On 05/31/2011 05:44 PM, Jason L Tibbitts III wrote:
>>>>>> "CK" == Christian Krause <chkr(a)fedoraproject.org> writes:
>
> CK> I have discussed this topic with upstream again, and there was an
> CK> agreement that mono assemblies are treated as platform independent
> CK> and so the original reason to change the paths is not valid anymore.
>
> Then we should move them to /usr/share.
>
> The point was that hardcoding /usr/lib is always wrong. If they're arch
> dependent, they should be in %{_libdir}. If not, /usr/share. So we
Why? ;-) The FHS uses the following definitions:
/usr/lib : Libraries for programming and packages
/usr/share : Architecture-independent data
Given just these definitions, libraries with byte code which needs an
interpreter / runtime environment, can still be considered being
libraries which would go into /usr/lib. "data" can also be interpreted
like: additional data files which are needed to execute a program (like
icons, game data, etc.). I haven not found any explicit rule that
"library" only refers to native ELF binaries.
> asked which it was and got the current answer. If the answer is
> different, then we have another change to make but currently what
> upstream does isn't right in either case.
Upstream would not agree with that statement.
The whole point of the suggested changes is to be closer to upstream.
The reasons are:
- Fedora's way produces lots of unnecessary work
- the changed paths causes lots of bugs
- the patches are rejected upstream
- upstream refuses to help with issues caused by changing the default paths
- Fedora encourages the maintainers to stay close to upstream
Putting the C# assemblies into %{_datadir} would not solve these problems.
Best regards,
Christian
13 years
dbus-sharp 0.7.0
by Denis Washington
Hi,
I wanted to install Docky 2.1.0 on my laptop, but noticed that the
current version in the Fedora repos is still 2.0.x. Rather than solve
the problem for me only and building the new version and its
dependencies from source, I decided to be a good citizen and try to
properly update the Docky package for Fedora.
I'm not finished with that yet, but I noticed that Fedora also doesn't
have the dbus-sharp 0.7.0 (F15 and rawhide have 0.63) which the new
Docky requires. Therefore, I would like to propose my work to update
dbus-sharp to the new version. My patch (against the
pkgs.fedoraproject.org repo) is attached to this message.
As dbus-sharp 0.7.0 changes the pkgconfig file name (dbus-sharp-1.0.git
instead of dbus-sharp.git), I looked for reverse dependencies with
repoquery against rawhide, which reveals "lat" as only package using it.
I have a second patch which adjusts its configure.ac to look for
dbus-sharp-1.0, and for dbus-sharp if the former fails. (I also posted
the patch upstream.) The patch, including the needed spec file changes,
are also attached here.
I hope the patches meet your quality expectations and can be integrated
into the Fedora repository.
Regards,
Denis Washington
P.S.: The dbus-sharp update removes both downstream patches as they
neither seem applicable nor needed anymore (the GTK+ requirement for the
examples seems to be removed).
13 years, 1 month
Deprecating multiarch support for mono in Fedora
by Christian Krause
Hi,
The way how mono is packaged in Fedora is uncommon with respect to
mono's default search paths:
In order to provide multi-arch support (32-bit and 64-bit packages
can be both installed on x86_64 systems), the standard mono's libdir
/usr/lib was changed to %{_libdir} (which is /usr/lib64 on x86_64).
Since this contradicts upstream's understanding of the directory
structure, this causes lots of unnecessary work for the maintainers and
quite a couple of bug reports due to uncaught uses of these default
paths within the mono packages. Nearly every mono package must be
adjusted and so the majority of all patches for mono consists solely of
%{_libdir} "fixes". Since it looks like that upstream (not only
mono-core, basically all mono-based packages) does not agree to these
changes, non of these patches are accepted upstream.
However, solving this issue would include to loose the ability to use
32bit parts of the mono stack in x86-64 - a feature which never worked
correctly and is not available for perl or python either.
Please see all details on the following wiki page I want to send in as
"feature" suggestion for F16:
https://fedoraproject.org/wiki/User:Chkr/MonoMultiarchChanges
My plan is to run this by the following groups to get their agreement:
- this mailing list ;-)
So please provide any feedback (positive and negative!) to the suggested
changes!
- Fedora packaging committee
Since the change affects how /usr/lib and /usr/lib64 are used for
mono-based packages in Fedora, I'd like to get their agreement, too.
- FEScO
For the final approval.
Please let me know you thoughts!
Best regards,
Christian
13 years, 1 month