I've reworked the Mono page to reflect the new Guidelines we confirmed yesterday. If people want to take a look, it's here: http://fedoraproject.org/wiki/PackagingDrafts/Mono
Changes are color coded: Red removes, green adds, blue is a justification for people who didn't attend the meeting and will be removed from the final copy. (I probably should have done this before the meeting rather than after, sorry.)
If no one objects, I'll replace the current Packaging/Mono page this weekend.
This is also an example of how the PackagingDrafts area could be used to work on new or revised Drafts. DavidLutterkort's RubyGems is another: http://fedoraproject.org/wiki/PackagingDrafts/RubyGems
-Toshio
On Fri, 2006-06-30 at 13:28 -0700, Toshio Kuratomi wrote:
I've reworked the Mono page to reflect the new Guidelines we confirmed yesterday. If people want to take a look, it's here: http://fedoraproject.org/wiki/PackagingDrafts/Mono
Changes are color coded: Red removes, green adds, blue is a justification for people who didn't attend the meeting and will be removed from the final copy. (I probably should have done this before the meeting rather than after, sorry.)
If no one objects, I'll replace the current Packaging/Mono page this weekend.
The guidelines now say "no noarch packages". What about packages such as lat, that are already in Extras as noarch and don't contain any arch-specific AOTs?
It does, however, install an mcs-built .dll and .exe in %{_prefix}/lib.
Is there anything technically wrong with this other than not lining up with the guidelines?
Paul.
On Sat, 2006-07-01 at 09:46 +0100, Paul Howarth wrote:
On Fri, 2006-06-30 at 13:28 -0700, Toshio Kuratomi wrote:
I've reworked the Mono page to reflect the new Guidelines we confirmed yesterday. If people want to take a look, it's here: http://fedoraproject.org/wiki/PackagingDrafts/Mono
Changes are color coded: Red removes, green adds, blue is a justification for people who didn't attend the meeting and will be removed from the final copy. (I probably should have done this before the meeting rather than after, sorry.)
If no one objects, I'll replace the current Packaging/Mono page this weekend.
The guidelines now say "no noarch packages". What about packages such as lat, that are already in Extras as noarch and don't contain any arch-specific AOTs?
The meeting log mentions that there are probably very few packages that contain pre-built AOTs (as opposed to glue-libraries which plainly go into %{_libdir}). The problem resides in the fact that the system administrator can choose to compile AOTs after installation of the package. Due to the fact that mono will only find AOTs that are in the same directory as the .dlls, the directory that the .dlls are in has to be the right one for an ELF shared object on that platform. This means /usr/lib for x86 and /usr/lib64 for x86_64.
It does, however, install an mcs-built .dll and .exe in %{_prefix}/lib.
It would need to be changed to %{_libdir} and non-noarch. The contents of the lat package may well be arch independent but doing this seems to be the least evil course to pursue WRT mono's limitations. This is also one of the issues that caused Debian to move mono from /usr/share to /usr/lib.
Is there anything technically wrong with this other than not lining up with the guidelines?
Hopefully the first paragraph explained that. If so, I'll try to merge that explanation into the guidelines.
-Toshio
Toshio Kuratomi wrote:
On Sat, 2006-07-01 at 09:46 +0100, Paul Howarth wrote:
The guidelines now say "no noarch packages". What about packages such as lat, that are already in Extras as noarch and don't contain any arch-specific AOTs?
The meeting log mentions that there are probably very few packages that contain pre-built AOTs (as opposed to glue-libraries which plainly go into %{_libdir}). The problem resides in the fact that the system administrator can choose to compile AOTs after installation of the package. Due to the fact that mono will only find AOTs that are in the same directory as the .dlls, the directory that the .dlls are in has to be the right one for an ELF shared object on that platform. This means /usr/lib for x86 and /usr/lib64 for x86_64.
It does, however, install an mcs-built .dll and .exe in %{_prefix}/lib.
It would need to be changed to %{_libdir} and non-noarch. The contents of the lat package may well be arch independent but doing this seems to be the least evil course to pursue WRT mono's limitations. This is also one of the issues that caused Debian to move mono from /usr/share to /usr/lib.
Is there anything technically wrong with this other than not lining up with the guidelines?
Hopefully the first paragraph explained that. If so, I'll try to merge that explanation into the guidelines.
Thanks for the explanation. I think it's very useful for guidelines to include the rationale behind them. It helps people to understand them and is also useful in determining whether an exception to the guidelines should be made, or indeed if the guidelines need updating to cover some case that hadn't been considered before.
I've now updated lat to use %{_libdir} instead of %{_prefix}/lib and be arch-specific:
http://cvs.fedora.redhat.com/viewcvs/devel/lat/lat.spec?root=extras&rev=...
Paul.
On Mon, 2006-07-03 at 15:30 +0100, Paul Howarth wrote:
Toshio Kuratomi wrote:
On Sat, 2006-07-01 at 09:46 +0100, Paul Howarth wrote:
The guidelines now say "no noarch packages". What about packages such as lat, that are already in Extras as noarch and don't contain any arch-specific AOTs?
The meeting log mentions that there are probably very few packages that contain pre-built AOTs (as opposed to glue-libraries which plainly go into %{_libdir}). The problem resides in the fact that the system administrator can choose to compile AOTs after installation of the package. Due to the fact that mono will only find AOTs that are in the same directory as the .dlls, the directory that the .dlls are in has to be the right one for an ELF shared object on that platform. This means /usr/lib for x86 and /usr/lib64 for x86_64.
It does, however, install an mcs-built .dll and .exe in %{_prefix}/lib.
It would need to be changed to %{_libdir} and non-noarch. The contents of the lat package may well be arch independent but doing this seems to be the least evil course to pursue WRT mono's limitations. This is also one of the issues that caused Debian to move mono from /usr/share to /usr/lib.
Is there anything technically wrong with this other than not lining up with the guidelines?
Hopefully the first paragraph explained that. If so, I'll try to merge that explanation into the guidelines.
Thanks for the explanation. I think it's very useful for guidelines to include the rationale behind them. It helps people to understand them and is also useful in determining whether an exception to the guidelines should be made, or indeed if the guidelines need updating to cover some case that hadn't been considered before.
I revised the File Locations section with the information about how the system administrator can create AOTs after install. Hopefully it's now clearer why we're making things arch-specific.
I'll copy this version over to the formal Packaging/ tree later today unless there are more suggestions.
-Toshio
packaging@lists.fedoraproject.org