Massrebuilds for GCC 4.3 coming soon to a buildsystem near you!

[Toshio Kuratomi]

David Nielsen wrote:
> 
> 
> 2008/2/11, Ignacio Vazquez-Abrams <ivazqueznet at gmail.com 
> <mailto:ivazqueznet at gmail.com>>:
> 
>     On Sun, 2008-02-10 at 20:42 +0100, David Nielsen wrote:
>      > 2008/2/10, Dan Horák <dan at danny.cz <mailto:dan at danny.cz>>:
>      >         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.
> 
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.

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080211/91e03027/attachment-0002.bin