Bug 247629 - Package should be 'noarch'
Package should be 'noarch'
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: ndesk-dbus (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: David Nielsen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-10 10:46 EDT by Alp Toker
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

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


Attachments (Terms of Use)

  None (edit)
Description Alp Toker 2007-07-10 10:46:45 EDT
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
sizes.
Comment 1 David Nielsen 2007-10-21 17:13:37 EDT
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.

http://fedoraproject.org/wiki/Packaging/Mono

--
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 12:45:20 EDT
David,

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
kidding.

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 13:02:58 EDT
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 13:45:33 EDT
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.