[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#813128: Fwd: Bug#813128: transition: openmpi



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Package: mpi-default-dev
Version: 1.2
Severity: wishlist

It has been discussed in
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813128
that some MPI packages build in two flavours (openmpi and mpich) and
need to know at upload time for which architecture each implementation
is available.

It has been proposed to add two variables to
/usr/share/mpi-default-dev/debian_defaults for this purpose.

Last iteration of this discussion below.

Mattia, it looks like there is a misunderstanding: in your commit,
OPENMPI_ARCHITECTURES and MPICH_ARCHITECTURES only list the
architectures for which each implementation is the default. The
feature that I would need for e.g. the yorick package is the list of
architectures on which each implementation is available. This is what
I currently check and hardcode by hand. I guess this is also what
other people do when they provide packages with distinct names for
each flavour.

Kind regards, Thibaut.

Le 16/02/2016 19:37, Mattia Rizzolo a écrit :
> On Tue, Feb 16, 2016 at 11:37:19AM +0100, Thibaut Paumard wrote:
>>> then mpi-defaults would need a sourceful uploads every single
>>> time a new architecture is added (and we want to support MPI
>>> there and openmpi builds), and also suddenly file a dozen RC
>>> bugs (as all packages using such a system would start to fail).
>>> Yes, we can do it, though.
> 
> See 
> https://anonscm.debian.org/cgit/debian-science/packages/mpi-defaults.g
it/commit/?id=07ef8a6
>
> 
https://anonscm.debian.org/cgit/debian-science/packages/mpi-defaults.git
/commit/?id=4fa28c2
> https://anonscm.debian.org/cgit/debian-science/packages/mpi-defaults.g
it/commit/?id=d9656b2
>
> 
>> So, what we want if to render RC buggy some packages that need a 
>> source upload whenever OPENMPI_ARCHITECTURES or
>> MPICH_ARCHITECTURES change.
> 
> Somebody needs to do that.  I can also have mpi-defaults provide a 
> script to be called by the packages at build time, if somebody
> provides it.
> 
>> An easier way would be for those packages to have a versioned 
>> dependency on mpi-default-dev and bump this version when either 
>> variable changes, e.g.
>> 
>> Build-Depends: mpi-default-dev (>= 1.3), mpi-default-dev (<<
>> 1.4~)
> 
> umh, looks messy.
> 
>> This is assuming the minor part of the version of
>> mpi-default-dev changes when either variable changes. The version
>> can then have also a micro digit, to allow for new versions that
>> don't change these variables
> 
> in the past mpi-defaults was binNMUed to change defaults; don't
> rely on that.
> 
>> Actually a versioned dependency seems required anyway since you
>> know your new package will FTBFS with earlier versions of
>> mpi-default-dev.
> 
> *shrugs*
> 
>> The only thing is that you can also predict that later versions
>> of mpi-default-dev will break your package.
>> 
>> This discussion getting off-topic for this bug, should we move 
>> somewhere else?
> 
> indeed. probably better suited for a mpi-defaults bug; feel free to
> open one and report a summary of what said here.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWw37SAAoJEJOUU0jg3ChA5aQQAK4G2ymR6jEzrU5aQ0kqxDwf
M2k1J/TyDPvXTW83uxF0IsZ2/BLBODyjY6yZAOefuLh65tr9g6fp/4uDWasHWfBE
aP5nwJ3AV3JEFeJQg6q7AVQOKqzViEaP3XaGl7KwSS2p0oy+blwiI5qXjU3XMNDt
d4LL3BrpPv6EvJVb77Sid22h7BG8l3DWMHN8lXX6NuuN4KMenAUV8cBoyKbffoeX
gTbkz3dNVMxhR2bHT3noSgUAOebKN2rmvLF2VpY/EvqwdGfvRQBc57k/kP9uNGXw
LhvYqQU4gxVd1FvJ7yoBikhabyA4iVnoOef1kDh8NaENLef+QvqCaJERy7bIGQeb
DkA4kmVOTB9jT/MzKoO7pfgTa3tnQJEDnkhPFci8udbd1sRQuujDTxD2ZUnCqrqx
aKD6Pfcju8ufDCycw/YTYXQ/M5cX879Yg4ih2swUy89eo98XffOYtwmIkYFTB1Me
OyWmvvLbKAuFniFu2cHS7FtllTqywARK+RXkN/qaIILOd7Jsp/JraaBWL6Ic9voq
jNGsl5BSihWA5oFoaUsJ535svk9u9+GO1025E5OAi5Sgj/HequSEQTQxnLPVy33+
ar6NmrXZSUSlQfTU58x7E1hI0JocM39wrGyNQHYm46kTliQr6LuHlJiWYf/scMaW
RLuXSIyzQutlnj5e15Iz
=mx4B
-----END PGP SIGNATURE-----


Reply to: