reopen 584789
stop
Hi
I'm sorry to insist; I hope my additional explanations make the issue
clearer.
On Sat, Jun 19, 2010, Mattias Ellert wrote:
> After a lengthy discussion the current install location was agreed upon.
>
> Your idea that the file is arch-specific is not strictly true. It is
> true that the file contains instructions for creating arch-specific
> content, but the file it self is not arch-specific since it can be used
> either in a 32 bit installation to create native content, or in a 64 bit
> installation to cross-compile 32 bit content. It is equally useful for
> both (or at least would be if Debian had a way to do a multilib
> installation).
The fact that the same file works for two arches doesn't mean it is
arch-independent. /usr/share is meant to contain data which could for
instance be shared over NFS, across architectures, even ARM and x86 for
instance.
(Besides cross-compilation and native compilation are very different
beasts, you can't equal cross-compilation for 32-bits to native
compilation on 32-bits).
> For the above reasons I do not consider the install location of this
> file to be in violation of the FHS, and this view was accepted by the
> ftp master reviewing the package before it was accepted.
Well, I challenge the correctness of this location.
globus-core_5.16-2_armel/usr/share/globus/libtool-gcc32pthr contains
things like:
build_alias=arm-linux-gnueabi
build=arm-unknown-linux-gnueabi
build_os=linux-gnueabi
and certainly this is incorrect on x86 systems.
I noticed this bug because we changed the GNU triplet of "i386" in
Ubuntu causing all packages build-depending on globus-core to FTBFS.
This is because usr/share/globus/libtool-gcc32pthr was encoding the old
triplet, instead of resolving the new one.
I don't strongly care about the FHS conformance or /usr/share on NFS
myself, which is why I filed the bug with severity normal, but this is
a clear violation of policy nevertheless, with a clear resolution (move
the file to /usr/lib). Moving the file back to /bin would also be an
acceptable solution, and would likely be better received upstream as
well; perhaps you can argue for a better name in /bin or keep the
slightly too generic name but rename the package containing it to
something-dev. If you chose to move the file to /usr/lib, consider
encoding the triplet in the pathname so that globus-core_armel and
globus_i386 etc. would be coinstallable in the case of a multiarch
aware dpkg.
I would highly recommend you consider getting rid of this file
altogether if that's an option, but if it needs to stay it certainly
can't stay in /usr/share if you want to comply to the FHS.
Thanks
--
Loïc Minier
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
