Re: [Fink-devel] openldap-ssl-shlibs-2.1.22-1 incompatible with cyrus-sasl2-shlibs-2.1.15-1 ?

2003-07-24 Thread Matt Stephenson
Hi Chris

I'm having no problems building openldap-ssl against cyrus-sasl2-2.1.15

checking for sasl/sasl.h... yes
checking for sasl.h... no
checking for sasl_client_init in -lsasl2... yes
checking Cyrus SASL library version... yes
Send me your config.log

Cheers
Matt
On Wednesday, Jul 23, 2003, at 21:55 Australia/Canberra, jfm wrote:

On Wednesday, Jul 23, 2003, at 11:00 Europe/Brussels, Christian 
Schaffner wrote:

checking for sasl/sasl.h... yes
checking for sasl.h... no
checking for sasl_client_init in -lsasl2... no
checking for sasl_client_init in -lsasl... no
configure: error: Could not locate Cyrus SASL
### execution of ./configure failed, exit code 1
Failed: compiling openldap-ssl-2.1.22-1 failed
My logs show the updates were done in the right order,
and I have :
checking for sasl/sasl.h... yes
checking for sasl.h... no
checking for sasl_client_init in -lsasl2... yes
checking Cyrus SASL library version... yes
checking for sasl_version... no
Maybe look in your config.log ?

Jean-Francois



---
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] Storable

2003-07-24 Thread David R. Morrison
To make sure that the old issues with Storable don't get in the way,
people need to be updated to at least fink-0.13.0 , which changed the way
that fink handles perl modules.  If people do that before trying to
upgrade Perl, they shouldn't have any problem with Storable.

Someone who upgrades Perl manually should certainly notify fink about it
by installing the system-perlxxx package (after upgrading Perl).  If you
upgrade Perl and haven't installed this module, then the next time you
update Fink you might get asked to either install this package or the
corresponding perl-corexxx package.

I hope that clarifies things.

  -- Dave


---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] Storable

2003-07-24 Thread Alexander Hansen
This seems clear enough..   I'll leave the old wording in place for now 
to support pre-0.13 users, and expand upon it.

On Thursday, July 24, 2003, at 09:22 AM, David R. Morrison wrote:

To make sure that the old issues with Storable don't get in the way,
people need to be updated to at least fink-0.13.0 , which changed the 
way
that fink handles perl modules.  If people do that before trying to
upgrade Perl, they shouldn't have any problem with Storable.

Someone who upgrades Perl manually should certainly notify fink about 
it
by installing the system-perlxxx package (after upgrading Perl).  If 
you
upgrade Perl and haven't installed this module, then the next time you
update Fink you might get asked to either install this package or the
corresponding perl-corexxx package.

I hope that clarifies things.

  -- Dave

Alexander K. Hansen
Levitated Dipole Experiment
http://www.psfc.mit.edu/LDX


---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel


[Fink-devel] pm dependencies

2003-07-24 Thread jfm
There is, if I'm not mistaken, a problem of correct deps
for a multi-perl fink installation.
Recall that some pm's (roughly, those installing a bundle)
must have Type: Perl x.y.z in their info file, and be built
with perlx.y.z, to be usable with perlx.y.z _ and those packages
get a name like foo-pmxyz.
If other, non-versioned, pm's have to Depend on those, one
needs an additional package foo-pm (Type: bundle), so the
dependency can get listed as just on foo-pm.
The problem is how to express correctly the dependency of
foo-pm on the different foo-pmxyz's: the effect should be that
foo-pm being installed is a certificate, for whatever perlx.y.z is
running, that the corresponding foo-pmxyz is there (and not just
some foo-pmx'y'z').
So here is a proposal:

We introduce for each xyz a package 'perlxyz_not' that conflicts
with perlxyz (where perlxyz is _ like eg perl580 _ a package that
basically just does ln -fs `which perlx.y.z`%p/bin/perl _ hence
conflicts with all other perlx'y'z') and with system-perlxyz: then we
can let all foo-pm depend on  perlxyz_not | foo-pmxyz  for all xyz.
This will require the user to install foo-pmxyz for all bundles
foo-pm and all perl versions x.y.z he has installed _ but there
are not that many bundles, and it seems a condition for a
reliable system.
Note that the 'perlxyz_not' packages are not logically necessary in
this proposal, they are just a shorthand to simplify the writing of the
Deps in the foo-pm packages : else each 'perlxyz_not' in those Deps
should be replaced by the alternative that some other perlx'y'z' is 
installed.

The system has some defects: eg, a user who would not install
perlxyz, just perlxyz-core, and try to use that _ either by using 
explicitly
perlx.y.z as command or by doing ln -s `which 
perlx.y.z`/usr/local/bin/perl
would not be protected.

Also, I'm afraid manual intervention will be required eg when a
user, who has nothing of say perl580 installed, and hence has 
perl580_not
installed, issues 'fink install perl580' : the logic is that
- since the user explicitly asks to install a package that conflicts 
with perl580_not,
the latter package will have to go.
- since there is a legal way to satisfy the user's request without 
removing any other
package, that's what should be done
[ The legal way: 1) build perl580
2) install perl580-core  3) build and install in build-order all 
foo-pm580
for which foo-pm is installed  4) remove perl580_not  5) install 
perl580 ]

But I don't think fink or dpkg's dependency engines are capable of this
(maybe apt-get ?), and some manual guidance  will be required here..
Comments ? Improvements or other suggestions ?

Jean-Francois Mertens



---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel