Re: ITP: mpi-defaults -- Meta-packages depending on appropriate MPI -dev and -bin packages for each platform
Now I can put dependencies of the newer release of my packages against
mpi-default-*. Actually, I even would prefer this as a permanent
solution instead of a temporary one. No bothering anymore about openmpi/
lam/mpich or whatsoever.
Gerber
On Fri, 2008-12-26 at 01:01 -0500, Adam C Powell IV wrote:
On Thu, 2008-11-20 at 09:45 -0500, Adam C Powell IV wrote:
On Thu, 2008-11-20 at 12:35 +0100, Ondrej Certik wrote:
On Thu, Nov 20, 2008 at 11:14 AM, Manuel Prinz
deb...@pinguinkiste.de wrote:
Am Mittwoch, den 19.11.2008, 09:05 -0600 schrieb Dirk
Eddelbuettel:
I think we should put either debian or mpi first. How about
mpi-default-{dev,bin}
or even
mpi-debian-default-{dev,bin}
to make it even clearer that it is just 'us' (ie Debian) defining a
default
for us, rather misconstruing that more than two decades (I'm guessing)
of
competing mpi implementations have ended ? ;-)
Good guessing. But I'm confident we can solve that problem in one way or
another in a shorter time frame.
Comments ?
Well, why not debian-default-mpi-{bin,dev}? ;)
Seriously, I do not care that much. A name is a name. If we're lucky,
the package might be gone by release of Squeeze.
I like Dirk's suggestion more:
mpi-default-{dev,bin}
But as you said, a name is just a name.
I like this suggestion, and have just posted the new package for comment
in the alioth debian-science repository:
git://git.debian.org/git/debian-science/packages/mpi-defaults.git
http://git.debian.org/?p=debian-science/packages/mpi-defaults.git;a=summary
It uses the PETSc system, which Build-Depends on an arch-dependent MPI
implementation, then rules uses readlink to determine which one is the
default alternative, and sets substvars appropriately, whether openmpi,
lam, or mpich*. That way, if we want to change the defaults, we just
need to change the Build-Depends in control. In many other ways it
follows the example of java-common.
This was just accepted! Yay! I'm now wishist bugging all of my
packages to use it, and will start uploading with hypre tonight.
-Adam
--
Gerber van der Graaf
GnuPG key fingerprint:
BF0A BBFE 5623 9761 C9E1 7C82 8B08 F586 D39A 2B64
http://gpiv.sourceforge.net/
--
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ITP: mpi-defaults -- Meta-packages depending on appropriate MPI -dev and -bin packages for each platform
Hi again, and sorry for causing accidental posts to
[EMAIL PROTECTED] -- I don't know how to do X-Debbugs-CC in
Evolution.
On Thu, 2008-11-20 at 12:35 +0100, Ondrej Certik wrote:
On Thu, Nov 20, 2008 at 11:14 AM, Manuel Prinz [EMAIL PROTECTED] wrote:
Am Mittwoch, den 19.11.2008, 09:05 -0600 schrieb Dirk Eddelbuettel:
I think we should put either debian or mpi first. How about
mpi-default-{dev,bin}
or even
mpi-debian-default-{dev,bin}
to make it even clearer that it is just 'us' (ie Debian) defining a default
for us, rather misconstruing that more than two decades (I'm guessing) of
competing mpi implementations have ended ? ;-)
Good guessing. But I'm confident we can solve that problem in one way or
another in a shorter time frame.
Comments ?
Well, why not debian-default-mpi-{bin,dev}? ;)
Seriously, I do not care that much. A name is a name. If we're lucky,
the package might be gone by release of Squeeze.
I like Dirk's suggestion more:
mpi-default-{dev,bin}
But as you said, a name is just a name.
I like this suggestion, and have just posted the new package for comment
in the alioth debian-science repository:
git://git.debian.org/git/debian-science/packages/mpi-defaults.git
http://git.debian.org/?p=debian-science/packages/mpi-defaults.git;a=summary
It uses the PETSc system, which Build-Depends on an arch-dependent MPI
implementation, then rules uses readlink to determine which one is the
default alternative, and sets substvars appropriately, whether openmpi,
lam, or mpich*. That way, if we want to change the defaults, we just
need to change the Build-Depends in control. In many other ways it
follows the example of java-common.
Also, I made it GPL 2+, and made the copyright in the model of
java-common.
Feedback anyone?
Cheers,
-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
http://www.opennovation.com/
signature.asc
Description: This is a digitally signed message part
Re: ITP: mpi-defaults -- Meta-packages depending on appropriate MPI -dev and -bin packages for each platform
Am Donnerstag, den 20.11.2008, 09:45 -0500 schrieb Adam C Powell IV: It uses the PETSc system, which Build-Depends on an arch-dependent MPI implementation, then rules uses readlink to determine which one is the default alternative, and sets substvars appropriately, whether openmpi, lam, or mpich*. That way, if we want to change the defaults, we just need to change the Build-Depends in control. In many other ways it follows the example of java-common. Sounds good. Also, I made it GPL 2+, and made the copyright in the model of java-common. I've no strong feelings about that. Feedback anyone? I was just wondering why you depend on debhelper = 3, while compat is set to 5. Souldn't you depend on = 5 then? All other things look good, though I did not test it yet. Thanks for your work! Best regards Manuel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: ITP: mpi-defaults -- Meta-packages depending on appropriate MPI -dev and -bin packages for each platform
On Thu, 2008-11-20 at 16:48 +0100, Manuel Prinz wrote: Am Donnerstag, den 20.11.2008, 09:45 -0500 schrieb Adam C Powell IV: Feedback anyone? I was just wondering why you depend on debhelper = 3, while compat is set to 5. Souldn't you depend on = 5 then? Not sure. My reasoning was that it doesn't require any capabilities of debhelper 3. But I think you're right, that's inconsistent and should be changed. All other things look good, though I did not test it yet. Thanks for your work! No problem, it was quite simple. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
