-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
- - --
PGP
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
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,
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
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
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.
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
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
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
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
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
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
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
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
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
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
16 matches
Mail list logo
