David Nielsen wrote:
I would oppose making the demand optional. It either makes sense or it doesn't. If it does make sense then %{_libdir} is the proper location. If it doesn't then %{_datadir} is the proper location.2008/2/11, Ignacio Vazquez-Abrams <ivazqueznet@xxxxxxxxx <mailto:ivazqueznet@xxxxxxxxx>>:On Sun, 2008-02-10 at 20:42 +0100, David Nielsen wrote: > 2008/2/10, Dan Horák <dan@xxxxxxxx <mailto:dan@xxxxxxxx>>: > The script included also some applications written in C# and > build with > Mono, are they really required to be rebuild? > > Pure managed code such as ndesk-dbus should not need a rebuild, thus I > was also surprised to find them on the list. If it's pure managed code then why is it in an arch-specific package?Because the guidelines for packaging Mono are IMHO broken, we do this to enable AOT after the fact, I have at least one upstream complaining loudly over this and personally I'm rather tired of patching the libdir stuff by hand. Would anyone oppose making that demand optional? As more and more code is becoming pure managed it would greatly reduce the work required to maintain these packages if we could be allowed to package them as noarch. Less patching, closer to upstream.. all that good stuff and I wouldn't be pulling out my hair everytime I feel like I'm writing yet another mindless patch that will never go upstream.
Many upstreams will take patches for this issue as long as they understand that the patch is making the location buildtime configurable. If they don't it seems to be for one of two reasons:
1) They don't understand or don't want to understand multilib. Therefore, they are willing to put things into /usr/lib and ignore the possible usage of /usr/lib64.
2) They are unwilling to work around mono's limitation on having AOT binaries in the same location as the mono assemblies.
Both Debian and Miguel have recommended that assemblies for mono be treated as architecture dependent rather than shipping in /usr/share so upstreams using argument #2 can be pointed at Miguel's post on the subject [1]_. Multilib is a fact of life for Fedora so you can try to persuade upstreams taking argument #1 that a proper build script will allow the right thing to happen on both multilib and non-multilib systems. Otherwise, yes, we do have to carry the patches to support our multilib environment just as we'd have to carry patches if an upstream C library was unresponsive to our requests to unbork their custom Makefiles.
[1]_: http://osdir.com/ml/linux.debian.packages.mono/2005-02/msg00007.html FHS section, points 3 & 4. -Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
