Bug 247629 - Package should be 'noarch'
Summary: Package should be 'noarch'
Alias: None
Product: Fedora
Classification: Fedora
Component: ndesk-dbus (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: David Nielsen
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-07-10 14:46 UTC by Alp Toker
Modified: 2007-11-30 22:12 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-21 21:13:37 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Alp Toker 2007-07-10 14:46:45 UTC
This package seems to be getting built on multiple architectures right now. In
fact the software is architecture independent and I believe should be 'noarch'.
This means that both ndesk-dbus and ndesk-dbus-glib can be built once and
installed on any supported platform, reducing build time and installation media

Comment 1 David Nielsen 2007-10-21 21:13:37 UTC
Thank you for your bugreport Alp, I value your expertise being upstream for said
packages however I'm closing this as NOTABUG.

Making the packages noarch would be in contradiction with the Mono packaging
guidelines as it would make post packaging AOT problematic.


File Locations

Mono packages should install assemblies to %{_libdir} rather than /usr/lib or
%{_datadir}. In most cases the preference is for %{_libdir}/PACKAGENAME. We use
%{_libdir} because we do not consider mono packages to be noarch.

The main reason for this is that mono can ahead-of-time compile its assemblies
into ELF shared objects. These AOTs have to exist in the same directory as their
DLL/EXE counterparts otherwise mono cannot use them. Even if we, as packagers,
choose not to create the AOT files when we build the mono rpms, the system
administrator can choose to create them after install. Since there's no way to
place the mono assemblies into an arch independent directory and the AOTs into
arch dependent directories, the whole thing has to go into an arch dependent tree.

Comment 2 Alp Toker 2007-10-22 16:45:20 UTC

The path where AOT shared objects go is just a hack to make life easier for the
developers, and it probably won't change until AOT makes things consistently
faster rather than slower.

AOT shared objects are conceptually equivalent to cache files, and they will
most likely eventually be stored in a cache path, perhaps in /usr/lib, perhaps
somewhere more temporary, but only when the feature starts to become useful.

Even when AOT support is complete, my understanding is that it won't be suitable
for packaging in distributions, because the generated machine code may be very
closely tied to the architecture at a much higher granularity than the list of
architectures supported by any distribution. These really are cache files, no

The very foundation of the Mono project is to provide portable libraries and
applications which don't have to be recompiled on different architectures. AOT
is a neat new feature that might speed things up when it's ready, but it has no
bearing on any packaging policies, and if AOT ever becomes supported, it will
obviously be made to follow filesystem hierarchy guidelines, rather than the
other way round.

This all makes a bit more sense if you consider what will end up in the RPM for
each architecture you support right now -- exactly the same thing, byte for
byte. This is pretty much the definition of a noarch package.

Comment 3 Peter Gordon 2007-10-22 17:02:58 UTC
Alp, we appreciate your explaining this. But as it stands, the AOTs must be in
the same directory as the bytecode (which _would_ theoretically be
arch-independent). The package itself must be made arch-specific so that the
bytecode libraries and AOTs share the same arch-specific directory when run.

Comment 4 David Nielsen 2007-10-22 17:45:33 UTC
I'll have to admit I do agree with Alp (hence why I originally changed the
package to be noarch). I'll leave the bug as closed but I will elevate the
packaging problem to the Mono SIG in hopes that we can get the guidelines
changed - for now my hands are tied though.

The guidelines seem to sabotage one of the fundamental benefits of using Mono
and it saddens me especially since it seems we are doing this for an obscure
cornercase. We should be about good defaults, the good default here would be to
have mono packages be noarch.

Note You need to log in before you can comment on or make changes to this bug.