mono June 2011

mono@lists.fedoraproject.org

5 participants
4 discussions

Re: dbus-sharp 0.7.0
by Christian Krause 15 Jun '11

15 Jun '11

Hi Paul, Hi All, On 05/29/2011 07:13 PM, Paul Howarth wrote: > On Sun, 29 May 2011 18:23:29 +0200 > Christian Krause <chkr(a)fedoraproject.org> wrote: >> Yep, dbus-sharp 0.7.0 (and dbus-sharp-glib-0.5.0) is needed for the >> new banshee 2.1.x as well. So I will update dbus-sharp to the new "version" from https://github.com/mono/dbus-sharp and push it through the review process since it is technically a new package. >> It is "lat" and "blam", although it looks like that blam actually uses >> ndesk-dbus and so the Requirement for dbus-sharp is just some remains >> from former times when blam used dbus-sharp. >> >> @blam-owners: Please can you check whether the dbus-sharp dependencies >> could be entirely dropped from the blam package? @blam-owners: Once we have update to dbus-sharp 0.7.0, I'm going to just drop this unneeded dependency blam. Please just let me know if you want to do the change yourself. >> @lat-owner, @Denis: Please can you take a look at this issue? > > I think lat is pretty much dead upstream. The last svn commit was 18 > months ago and the person maintaining it isn't the original author, who > abandoned it a long time ago. I think it's probably time to retire it. Ok, that's certainly an option. ;-) Since an update to dbus-sharp will cause missing dependencies for the lat package, please can you officially retire lat in rawhide? Thanks! Best regards, Christian

2 1

Re: [Fedora-packaging] Changing default paths for mono packages
by John Dennis 03 Jun '11

03 Jun '11

On 05/31/2011 11:44 AM, Jason L Tibbitts III wrote: > And, yes, python is still wrong in using /usr/lib the way it does. I'd > hope that we could fix that with python3 but somehow that didn't work > out. Huh? Python contains *both* noarch and arch specific libraries (e.g. .so's) which are collocated in the same directories. To the best of my knowledge there is no standard mechanism in Python which would allow segregating the noarch ans arch specific files into different search paths *and* properly resolve module loading when noarch and arch specific modules are interdependent by sub-path location. FWIW, Java has a similar problem with noarch files (.class & .jar) and JNI native .so files. There was discussion in the Java SIG group a number of weeks back and I'm not sure there was resolution, what I do recall was there was decent amount of disagreement over the proper packaging approach. Bottom line seems to be that we need to address the packaging issues of languages supporting a mix of byte compiled noarch libraries and arch specific "native" libraries at a higher level and then form language specific rules derived from the general principles. What we don't want to continue doing is promulgating the band-aid inconsistent one-off rules, suggestions and domain specific policies. I've spent an unreasonable amount of time trying to deal with these issues and I can testify it's a mess and the whole problem seems poorly understood and our tools poorly equipped to deal with it. To be perfectly honest if you ask me "multi-lib" is currently a hack with a lot of warts and dark corners because we tried to graft the concept of multi-lib on top of a tool chain and policies which were never meant to support the concept. -- John Dennis <jdennis(a)redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/

2 1

Changing default paths for mono packages
by Christian Krause 03 Jun '11

03 Jun '11

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

4 6

Re: [Fedora-packaging] Changing default paths for mono packages
by Christian Krause 03 Jun '11

03 Jun '11

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

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mono June 2011