Dave,
If you intend to allow lammpi and lammpi2 to coexist, then files
will have to be moved in the old lammpi package. Specifically you will
have to duplicate what I did for the new lammpi and openmpi packages
where the mpicc, mpic++ and mpif77 compilers have been converted into
symlinks which
On Jul 20, 2006, at 2:52 PM, Jack Howarth wrote:
> Dave,
> I understand how shared libraries are linked and acutely
> aware that the dpkg/apt-get in fink is brain-dead in regard to
> providing the appropriate shared library dependency information
> compared to Debian.
On the contrary. Darw
On Thu, Jul 20, 2006 at 02:52:49PM -0400, Jack Howarth wrote:
> Dave,
> I understand how shared libraries are linked and acutely
> aware that the dpkg/apt-get in fink is brain-dead in regard to
> providing the appropriate shared library dependency information
> compared to Debian. The reason t
Dave,
One other observation as to why lammpi is somewhat of a special
case. Currently in fink 10.4 stable, lammpi only builds for powerpc
because it BuildDepends on g77. As part of the revamping of the lammpi
package, I changed the BuildDepends of gfortran so that we could have
a lammpi package
Dave,
I understand how shared libraries are linked and acutely
aware that the dpkg/apt-get in fink is brain-dead in regard to
providing the appropriate shared library dependency information
compared to Debian. The reason that the lammpi shared libraries
are moved is to duplicate the approach
Jack,
Let me try to explain this again. It has nothing to do with software
built outside of fink, it has only to do with the way that the fink
packaging system works.
I'm going to explain this slowly, since we are miscommunicating, so
please be patient and read the whole thing! In fact, t
Dave,
Renaming the package at this point would likely cause more
far breakage than it would resolve. There are only a couple of
packages that use lammpi currently and they have all been
version bumped to required the newer packaging. If we rename
the the new lammpi, we would have forcibly regre
On Jul 20, 2006, at 9:13 AM, Jack Howarth wrote:
> Chris,
> If I understand fink correctly, adding...
>
> Replaces: lammpi (<< 7.1.2-1000)
>
> ...after...
>
> BuildConflicts: lammpi (<< 7.1.2-1000), lammpi-shlibs (<<
> 7.1.2-1000), lammpi-dev
> Conflicts: lammpi (<< 7.1.2-1000), lammpi-shli
Chris,
If I understand fink correctly, adding...
Replaces: lammpi (<< 7.1.2-1000)
...after...
BuildConflicts: lammpi (<< 7.1.2-1000), lammpi-shlibs (<< 7.1.2-1000),
lammpi-dev
Conflicts: lammpi (<< 7.1.2-1000), lammpi-shlibs (<< 7.1.2-1000), lammpi-dev
(<< 7.1.2-1000)
for the openmpi pac
On Jul 19, 2006, at 2:27 PM, Jack Howarth wrote:
> Would it be possible to somehow modify fink to handle the
> following
> case. When I created the openmpi package and modified the lammpi to
> co-exist with it, I ran into a limitation of fink. If a user has
> already installed the previous
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 19, 2006, at 7:13 PM, Jack Howarth wrote:
> Conflicts: lammpi (<< 7.1.2-1000), lammpi-shlibs (<< 7.1.2-1000),
> lammpi-dev (<< 7.1.2-1000)
add a replaces: line with the packages/versions that it shares files
with.
- -chris zubrzycki
- -
Daniel,
I already have...
Depends: %N-shlibs (= %v-%r)
BuildDepends: gcc4 (>> 4.1.-20060610)
BuildConflicts: lammpi (<< 7.1.2-1000), lammpi-shlibs (<< 7.1.2-1000),
lammpi-dev
Conflicts: lammpi (<< 7.1.2-1000), lammpi-shlibs (<< 7.1.2-1000), lammpi-dev
(<< 7.1.2-1000)
...in the current
On Wed, Jul 19, 2006 at 02:27:38PM -0400, Jack Howarth wrote:
> Would it be possible to somehow modify fink to handle the following
> case. When I created the openmpi package and modified the lammpi to
> co-exist with it, I ran into a limitation of fink. If a user has
> already installed the pr
Would it be possible to somehow modify fink to handle the following
case. When I created the openmpi package and modified the lammpi to
co-exist with it, I ran into a limitation of fink. If a user has
already installed the previous lammpi package and directly tries to
install the new openmpi p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello guys.
Could we lock during a selfupdate?
When a slow CVS selfupdate runs and you try to install "fink install fink",
you will get errors like these:
"Reading package info...can't open
/sw/fink/dists/unstable/main/finkinfo/sci/nco.info: No such
Fair enough. I'm happy that it is so easy to change compile time
options. But I'm still interested in a more "intelligent" software
managing system for sometime down the road. One would have to do a
lot of prep work, however, it seems quite conceivable that one would
be able to leverage the softw
Actually I've been meaning to do up a document on this, for the benefit
of users who want to muck around with their compile-time options. The
day job keeps interfering, though.
--
Alexander Hansen
Levitated Dipole Experiment
http://www.psfc.mit.edu/LDX
On Feb 4, 2004, at 3:08 PM, Joe Corneli wr
Joe Corneli wrote:
I'm really talking about two things, one of which is no problem.
1. being able to change compile time options
No problem, its already possible. Everyone agrees that you better
know roughly what you're doing, or the package won't work.
2. being able to dynamically find & sat
I'm really talking about two things, one of which is no problem.
1. being able to change compile time options
No problem, its already possible. Everyone agrees that you better
know roughly what you're doing, or the package won't work.
2. being able to dynamically find & satisfy dependencies
Remi Mommsen wrote:
[]
on. You are asking for an interactive mode for creating package files...
In addition it violates the fink policy that a deb file with a given
name/version/revision should be identical regardless how and where it
was built.
It violates the even more important principle that
This sounds a lot like portage.
On Feb 3, 2004, at 8:46 PM, Joe Corneli wrote:
You hit the nail on the head there. It isn't just the compile-time
options, but several details of the lynx configuration file that
need to be fiddled with. However, the problem with making a new
package is we'd proba
You are asking for an interactive mode for creating package
files... In addition it violates the fink policy that a deb file
with a given name/version/revision should be identical regardless
how and where it was built.
It would be possible to save the interactively generated file with
Hi Joe,
On Feb 3, 2004, at 4:28 PM, Joe Corneli wrote:
For the finicky fink user, it would be nice to be able to inspect
and modify the configuration options at build time - so something
like
% fink finicky-install lynx-ssl
These options will be passed to configure:
--enable-nls --with-screen=ncu
For the finicky fink user, it would be nice to be able to inspect
and modify the configuration options at build time - so something
like
% fink finicky-install lynx-ssl
These options will be passed to configure:
--enable-nls --with-screen=ncurses --disable-full-paths --enable-file-upload
--enable
24 matches
Mail list logo