David Nielsen wrote:
>
>
> 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.
>
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.
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
