FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

 
 
LinkBack Thread Tools
 
Old 05-30-2011, 10:07 PM
Christian Krause
 
Default Changing default paths for mono packages

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
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 05-31-2011, 03:44 PM
"Jason L Tibbitts III"
 
Default Changing default paths for mono packages

>>>>> "CK" == Christian Krause <chkr@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
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.

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.

- J<
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 05-31-2011, 03:45 PM
"Jason L Tibbitts III"
 
Default Changing default paths for mono packages

And, lovely, crossposting to a list I can't post to.

- J<
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 05-31-2011, 04:02 PM
Toshio Kuratomi
 
Default Changing default paths for mono packages

On Tue, May 31, 2011 at 12:07:17AM +0200, Christian Krause wrote:
>
> 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?
>
This section is a bit unclear to me:
"""
Reverting this decision and using again mono's standard search path /usr/lib
would result in conflicts between i686 and x86_64 packages because both
would contain the same files (possibly with different content). That means,
that we would have to prevent that any mono i686 package would be drawn into
the x86_64 repos and so we would 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 other run-time environments like perl or python either.
"""

1) We should be creating noarch packages (not x86 and x86_64 specific
packages) if these packages contain architecture independent code, correct?

2) This section says that the same files might have different content. Do
you have a list of the things that cause differences between compilations on
the different architectures? If it's just things like timestamps, that
should be fine as those won't cause problems when trying to run them on
other architectures. But I'm not sure if that's pretty much what it's
restricted to.

-Toshio
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 05-31-2011, 05:47 PM
Christian Krause
 
Default Changing default paths for mono packages

On 05/31/2011 05:45 PM, Jason L Tibbitts III wrote:
> And, lovely, crossposting to a list I can't post to.

Sorry for that. Postings from non-members were rejected due to the
massive amount of spam. I have just allowed postings for non-members
again (at least for this discussion).

Best regards,
Christian
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 05-31-2011, 06:20 PM
Christian Krause
 
Default Changing default paths for mono packages

Hi,

On 05/31/2011 05:44 PM, Jason L Tibbitts III wrote:
>>>>>> "CK" == Christian Krause <chkr@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
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 05-31-2011, 07:01 PM
Christian Krause
 
Default Changing default paths for mono packages

Hi,

On 05/31/2011 06:02 PM, Toshio Kuratomi wrote:
> This section is a bit unclear to me:
> """
> Reverting this decision and using again mono's standard search path /usr/lib
> would result in conflicts between i686 and x86_64 packages because both
> would contain the same files (possibly with different content). That means,
> that we would have to prevent that any mono i686 package would be drawn into
> the x86_64 repos and so we would 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 other run-time environments like perl or python either.
> """
>
> 1) We should be creating noarch packages (not x86 and x86_64 specific
> packages) if these packages contain architecture independent code, correct?

In general yes. ;-) That's the way how OpenSUSE handles it.

However, even if it would be easy for packages like "monodevelop", which
contain only C# assemblies and no ELF libraries there may be problems
with packages like f-spot, which contains mostly C# assemblies but also
include one "glue code" ELF library. Should the package then be split?
That sounds a little bit like overkill just for the purpose of having
100% pure correctness of the packages without solving any real problems.
;-)

> 2) This section says that the same files might have different content. Do
> you have a list of the things that cause differences between compilations on

No, I don't have a specific list.

> the different architectures? If it's just things like timestamps, that
> should be fine as those won't cause problems when trying to run them on
> other architectures. But I'm not sure if that's pretty much what it's
> restricted to.

Given all information I got so far the assemblies should be compatible.
To verify this I have just tested it with f-spot:

On an x86_64 system with f-spot installed I have copied all C#
assemblies from the i686 package into the same location where the x86_64
package had put them. F-spot still worked fine.

So yes, the C# assemblies differ on binary level, but they are
compatible between i686 and x86_64.

I have also verified this with the mono disassembler:
----------------------------------------------
# diff -u <(monodis
/tmp/f-spot-0.8.2-1.fc14.i686/usr/lib/f-spot/TagLib.dll) <(monodis
/tmp/f-spot-0.8.2-1.fc14.x86_64/usr/lib64/f-spot/TagLib.dll)
--- /proc/self/fd/63 2011-05-31 20:57:01.172361683 +0200
+++ /proc/self/fd/62 2011-05-31 20:57:01.172361683 +0200
@@ -20,9 +20,9 @@

.custom instance void class
ApplicationBuildInformationAttribute::'.ctor'(stri ng, string, string,
string) = (
01 00 0E 73 6F 75 72 63 65 2D 74 61 72 62 61 6C //
...source-tarbal
- 6C 09 6C 69 6E 75 78 2D 67 6E 75 04 69 33 38 36 //
l.linux-gnu.i386
- 17 32 30 31 30 2D 31 32 2D 33 30 20 31 39 3A 34 //
.2010-12-30 19:4
- 35 3A 34 37 20 55 54 43 00 00 ) //
5:47 UTC..
+ 6C 09 6C 69 6E 75 78 2D 67 6E 75 06 78 38 36 5F //
l.linux-gnu.x86_
+ 36 34 17 32 30 31 30 2D 31 32 2D 33 30 20 31 39 //
64.2010-12-30 19
+ 3A 34 35 3A 33 32 20 55 54 43 00 00 ) //
:45:32 UTC..

.custom instance void class
[mscorlib]System.Reflection.AssemblyTitleAttribute::'.ctor'( string) =
(01 00 06 46 2D 53 70 6F 74 00 00 ) // ...F-Spot..

@@ -51,7 +51,7 @@
.hash algorithm 0x00008004
.ver 0:8:0:0
}
-.module TagLib.dll // GUID = {0FA349CD-45CF-4BFE-ACE9-D11F3234C49E}
+.module TagLib.dll // GUID = {BFB9521F-4DBB-4D35-8CD0-CBDC908E0D54}


.namespace TagLib.Aac
----------------------------------------------

Best regards,
Christian
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 05-31-2011, 09:43 PM
Toshio Kuratomi
 
Default Changing default paths for mono packages

On Tue, May 31, 2011 at 09:01:00PM +0200, Christian Krause wrote:
> Hi,
>
> On 05/31/2011 06:02 PM, Toshio Kuratomi wrote:
> > This section is a bit unclear to me:
> > """
> > Reverting this decision and using again mono's standard search path /usr/lib
> > would result in conflicts between i686 and x86_64 packages because both
> > would contain the same files (possibly with different content). That means,
> > that we would have to prevent that any mono i686 package would be drawn into
> > the x86_64 repos and so we would 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 other run-time environments like perl or python either.
> > """
> >
> > 1) We should be creating noarch packages (not x86 and x86_64 specific
> > packages) if these packages contain architecture independent code, correct?
>
> In general yes. ;-) That's the way how OpenSUSE handles it.
>
> However, even if it would be easy for packages like "monodevelop", which
> contain only C# assemblies and no ELF libraries there may be problems
> with packages like f-spot, which contains mostly C# assemblies but also
> include one "glue code" ELF library. Should the package then be split?
> That sounds a little bit like overkill just for the purpose of having
> 100% pure correctness of the packages without solving any real problems.
> ;-)
>
Well, it seems like the problems with conflicts between x86 and x86_64 would
be solved by making noarch packages. The splitting of packages is just
making a noarch subpackage so it's pretty straightforward. It doesn't seem
like too much overkill, is more correct as you point out, and is a natural
extension of the way pure C# would be packaged.

OTOH, with other languages (for instance python) only some things end up
multilibbed. For instance, python-libs (from the python package) is
multilib and pygtk2-devel is multilib (but not pygtk2 itself).
python-pycurl is an example of a package that is not multilibbed. So... eh,
your argument makes enough sense to me.

> > 2) This section says that the same files might have different content. Do
> > you have a list of the things that cause differences between compilations on
>
> No, I don't have a specific list.
>
> > the different architectures? If it's just things like timestamps, that
> > should be fine as those won't cause problems when trying to run them on
> > other architectures. But I'm not sure if that's pretty much what it's
> > restricted to.
>
> Given all information I got so far the assemblies should be compatible.
> To verify this I have just tested it with f-spot:
>
> On an x86_64 system with f-spot installed I have copied all C#
> assemblies from the i686 package into the same location where the x86_64
> package had put them. F-spot still worked fine.
>
> So yes, the C# assemblies differ on binary level, but they are
> compatible between i686 and x86_64.
>
> I have also verified this with the mono disassembler:
> ----------------------------------------------
> # diff -u <(monodis
> /tmp/f-spot-0.8.2-1.fc14.i686/usr/lib/f-spot/TagLib.dll) <(monodis
> /tmp/f-spot-0.8.2-1.fc14.x86_64/usr/lib64/f-spot/TagLib.dll)
> --- /proc/self/fd/63 2011-05-31 20:57:01.172361683 +0200
> +++ /proc/self/fd/62 2011-05-31 20:57:01.172361683 +0200
> @@ -20,9 +20,9 @@
>
> .custom instance void class
> ApplicationBuildInformationAttribute::'.ctor'(stri ng, string, string,
> string) = (
> 01 00 0E 73 6F 75 72 63 65 2D 74 61 72 62 61 6C //
> ...source-tarbal
> - 6C 09 6C 69 6E 75 78 2D 67 6E 75 04 69 33 38 36 //
> l.linux-gnu.i386
> - 17 32 30 31 30 2D 31 32 2D 33 30 20 31 39 3A 34 //
> .2010-12-30 19:4
> - 35 3A 34 37 20 55 54 43 00 00 ) //
> 5:47 UTC..
> + 6C 09 6C 69 6E 75 78 2D 67 6E 75 06 78 38 36 5F //
> l.linux-gnu.x86_
> + 36 34 17 32 30 31 30 2D 31 32 2D 33 30 20 31 39 //
> 64.2010-12-30 19
> + 3A 34 35 3A 33 32 20 55 54 43 00 00 ) //
> :45:32 UTC..
>
> .custom instance void class
> [mscorlib]System.Reflection.AssemblyTitleAttribute::'.ctor'( string) =
> (01 00 06 46 2D 53 70 6F 74 00 00 ) // ...F-Spot..
>
> @@ -51,7 +51,7 @@
> .hash algorithm 0x00008004
> .ver 0:8:0:0
> }
> -.module TagLib.dll // GUID = {0FA349CD-45CF-4BFE-ACE9-D11F3234C49E}
> +.module TagLib.dll // GUID = {BFB9521F-4DBB-4D35-8CD0-CBDC908E0D54}
>
>
> .namespace TagLib.Aac
> -----------
>
Huh. That linux-gnu.i386 vs linux-gnu.x86_64 line seems a bit fishy but
apparently that's only informational, mono isn't doing anything with it?

I don't see anything else that might be problematic in there.

-Toshio
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 06-02-2011, 04:08 PM
John Dennis
 
Default Changing default paths for mono packages

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@redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 06-02-2011, 09:37 PM
Christian Krause
 
Default Changing default paths for mono packages

Hi,

On 06/01/2011 08:13 AM, Paul F. Johnson wrote:
>>> 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
>
> I think that page needs updating for /usr/lib otherwise /lib64 is pretty
> pointless!

/usr/lib64 is mentioned in the next section:
/usr/lib<qual> : Alternate format libraries (optional)

> Upstream for many many year have been saying that as mono assemblies
> (actual programmes such as monodevelop rather than the gmcs compiler
> etc) should be placed in %{_datadir} as they are not arch (or even
> operating system) specific.

I think Toshio made a good point here: we have to distinguish between

a) the fact whether a library or an executable is arch-dependent or not

and

b) whether, in case of arch-independence, the files should be placed in
/usr/lib or /usr/share

For a) seems to be the agreement that C# assemblies are arch independent.

Regarding b) I'm convinced that it is well within the definition of the
FHS to place arch-independent libraries into /usr/lib. Sure, /usr/share
must only contain arch-independent files, but this does not mean, that
all arch-independent files must go into /usr/share. ;-)


Regarding the use of %{_datadir}: Do you have any reference when
upstream explicitly asked for that? At least their response to my
question was quite clear to use the paths defined by upstream (which is
/usr/lib).

> I've always been of the opinion with mono that upstream seriously don't
> know where they want to put things. In some cases the automake/conf bits
> point to %(libdir) macro and then in the code itself, it's hard coded
> to /usr/lib

AFAIK I see mostly fixes on their side changing %{_libdir} to
%{prefix}/lib. So it looks like that upstream treats the usage of
%{_libdir} as a bug.

> We do it right. Eventually others will follow.

Hm, I don't believe that upstream will ever adapt to Fedora's way of
packaging mono....


Best regards,
Christian
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 

Thread Tools




All times are GMT. The time now is 09:54 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org