Re: dbus-sharp 0.7.0
by Christian Krause
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
12 years, 10 months
Re: [Fedora-packaging] Changing default paths for mono packages
by John Dennis
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/
12 years, 10 months
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
12 years, 10 months
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
12 years, 10 months