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

[David Nielsen]

2008/2/11, Toshio Kuratomi <a.badger at gmail.com>:
>
> 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.
>

You make a very convincing argument.. however in the interest of being
diplomatic with the nice people who develop these fine tools, I think the
smartest thing is to carry the patches and not argue with them - I think
it's a case of respecting upstreams opinion even if it's wrong. They will
come around the more distributions carry such patches I hope.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080211/a2c232de/attachment.htm>