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
Hi,
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!
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.
Only problem has been doing it as to do it, you'd need links back to the assemblies which live in different places.
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
We do it right. Eventually others will follow.
PFJ
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
Hi,
/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)
What I mean is that it should read /usr/lib<qual> in the main part rather than in a sub-section ;)
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
All applications that use mono *should* be arch-independent. The libs are not arch independent.
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.
Yep...
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. ;-)
I have a feeling that the reason for using /usr/lib64 was set many moons ago (just after mono was accepted into Fedora) - it seemed logical.
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).
Right, let's jump back into our respective TARDIS/other time machine of your choice. Ready? Wvworp Wvworp Wvworp Meeglarp Meeglarp Floobp Floobp...
Way back (something like 2001ish) when Ximian released their embrionic mono/mcs application, Miguel stated that the plan was "for now" to keep things in %(libdir) (note, this is *not* our %{_libdir} but /usr/lib) and to move things to %(datadir) (this is our %{_datadir}) at some point as all applications would be platform independent and this would make life easy for the different array of platforms out there.
ISTR a big debate on the Ximian mailing lists over this (it rattled on for ages - and I mean ages). The largest noise came from those on the just released 64 bit system. They found building mono a complete pain due to the %{_libdir) vs %(libdir) problem. This was again cited as a reason to move to %{_datadir}
Eventually out of the mists two parties did arise. Those who would use /usr/lib and those who knew what they were doing and corrected things to use %{_libdir} otherwise their 64 bit systems would get messed up beyond belief!
Those from the %{_libdir} side of things regularly submitted the corrected patches to Ximian (then Novell and now Microsoft t/a Attachmate) who pondered them and then dumped them, citing the move to %{_datadir} still being on the cards...
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.
Some do, some don't. It's a bug, but only in a mirror dimension.
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....
Their choice. Just because the world drives Ford cars doesn't make them right...
TTFN
PFJ
mono@lists.stg.fedoraproject.org
-
Christian Krause -
Paul F. Johnson