Bug 217854 - sci-libs/hdf5-1.6.6 - use package.use.mask instead of putting arch in DEPEND
|
Bug#:
217854
|
Product: Gentoo Linux
|
Version: 2008.0_beta1
|
Platform: Sparc
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: sci@gentoo.org
|
Reported By: jer@gentoo.org
|
|
Component: Applications
|
|
|
URL:
|
|
Summary: sci-libs/hdf5-1.6.6 - use package.use.mask instead of putting arch in DEPEND
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2008-04-15 20:31 0000
|
It's better to add 'sci-libs/hdf5 mpi' to sparc profiles (so that emerge -p
hdf5 would show the USE flag as masked), than to put this sort of stuff in the
ebuilds (where USE=mpi would appear useful but is silently ignored).
Index: hdf5-1.6.6.ebuild
===================================================================
RCS file: /var/cvsroot/gentoo-x86/sci-libs/hdf5/hdf5-1.6.6.ebuild,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -B -r1.5 -r1.6
--- hdf5-1.6.6.ebuild 9 Apr 2008 01:34:59 -0000 1.5
+++ hdf5-1.6.6.ebuild 15 Apr 2008 14:06:33 -0000 1.6
@@ -1,6 +1,6 @@
# Copyright 1999-2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/sci-libs/hdf5/hdf5-1.6.6.ebuild,v 1.5
2008/04/09 01:34:59 jer Exp $
+# $Header: /var/cvsroot/gentoo-x86/sci-libs/hdf5/hdf5-1.6.6.ebuild,v 1.6
2008/04/15 14:06:33 markusle Exp $
inherit eutils fixheadtails flag-o-matic fortran toolchain-funcs
@@ -10,12 +10,12 @@
LICENSE="NCSA-HDF"
SLOT="0"
-KEYWORDS="~amd64 ~hppa ~ppc ~ppc64 ~x86"
+KEYWORDS="~amd64 ~hppa ~ppc ~ppc64 ~x86 ~sparc"
# need to update szip to get alpha, ia64, etc back in here,
IUSE="cxx debug fortran mpi ssl szip threads tools zlib "
-DEPEND="mpi? ( >=sys-cluster/mpich2-1.0.6
- net-fs/nfs-utils )
+DEPEND="!sparc? ( mpi? ( >=sys-cluster/mpich2-1.0.6
+ net-fs/nfs-utils ) )
ssl? ( dev-libs/openssl )
szip? ( sci-libs/szip )
zlib? ( sys-libs/zlib )
[...]
Did you try testing to see if it works at this point, instead of masking it?
It would indeed have been better to fix this in the sparc
profile itself. Please feel free to do this. I am always very
hesitant with messing around in profiles of arches I don't
know anything about, which is probably why I decided to
go the ebuild route. For future reference, is changing arch
profiles in this way an ok thing for me to do?
In any case, if at all possible, it would be best to keyword
sys-cluster/mpich2 and also sys-cluster/openmpi (which will
likely be the future mpi workhorse) on sparc.
Thanks for your patience.
Best,
Markus
Should be really easy to fix. hdf5 depends on virtual/mpi which gives 4
alternatives - if any of those MPI implementations works, then only that
implementation should be keyworded for sparc. I'll give openmpi a whirl.
Also note that only arch team members should normally edit arch profiles, and
that your hesitation isn't out of place at all.
OK, sys-cluster/lam-mpi and sys-cluster/mpich2 are keyworded already (even
though for the latter, sparc and ia64 keywords were dropped - I do not know
whether this was done in an appropriate manner). As it is now, virtual/mpi
should already work for sparc or it shouldn't be used at all - if a new-style
virtual doesn't implement compatible (drop in replacement) alternatives then it
shouldn't be used.
Besides, if openmpi is going to be the best of four alternatives in the future,
then the order of the alternative packages in virtual/mpi-1.0.ebuild should
probably be changed:
RDEPEND="|| (
sys-cluster/mpich
sys-cluster/lam-mpi
sys-cluster/openmpi
sys-cluster/mpich2
)"
> Besides, if openmpi is going to be the best of four alternatives in the future,
> then the order of the alternative packages in virtual/mpi-1.0.ebuild should
> probably be changed:
We're working on it, I'm adding sparc to the keywording request :)
See bug #216120
openmpi is now keyworded ~sparc.
Thanks much, Ferris! hdf5 currently hard depends
on mpich2. I'll have to check if it can handle
openmpi so we can depend on it and revive the mpi
useflag on sparc.
cheers,
Markus
Unfortunately, I don't currently have the time
to investigate this in any depth. In the meantime,
would it be possible for the spark team to mask USE='mpi' in
their profile so we can remove it from DEPEND until
somebody has the time to investigate the mpi situation.
Thanks much.
Markus
(In reply to comment #10)
> Done :)
>
Thank you very much! However, I think you masked
mpi globally in use.mask rather than only for hdf5
in package.use.mask. The mpi useflag itself should
be fine since sys-cluster/openmpi is keyworded on
sparc; only mpich2 which hdf5-1.6.6. depends on
is missing.
Thanks,
Markus
Right, virtual/mpi can be provided by openmpi and lam-mpi on sparc.
I moved it to package.use.mask
Great and thank you very much! I've removed sparc from
DEPEND in the ebuild.
Thanks,
Markus