On Wed, Aug 16, 2006 at 03:24:37PM +0200, Martin Costabel wrote: > David R. Morrison wrote: > >> *From: *Peter Dyballa <[EMAIL PROTECTED] > [] > >> When I want to install libpng3 Fink wants to install glib and > >> glib-shlibs too. What have these "Common C routines used by Gtk+ and > >> other libs" to do with PNG? > > This comes from two deliberate decisions in Fink: > > 1. Every package that installs a *.pc file must have a dependency on the > pkgconfig package. [snip] > In the case of libpng3, 1. is questionable, IMHO. It does not use > pkg-config, it simply installs two files into /sw/lib/pkgconfig/.
IIRC, we've never even had a consensus on this policy...didn't used to be required, then it was for a while, now not. Okay, let's resolve it now: should packages that contain .pc files be required to Depends:pkgconfig? Pro 1: .pc is a data file for pkg-config, so it doesn't make sense to have data files without their accessor program (would be like having foo-pmXXX not Depends:perlXXX-core). Pro 2 (Response to Con 1): People install foo-dev to be able to compile against libfoo and compiling against a lib that supplies .pc often requires using pkg-config, so we should reduce the number of unstated dependencies, especially for non-fink uses. The pkgconfig package is not BuildDependsOnly. Pro 3: Some ./configure for packages that install .pc actually use the pkg-config program (to determine where to install the .pc) using various hacks that don't make it obvious this is happening. Setting the dependency, at least as a BuildDepends, thus leads to reduced packaging problems. Pro 4: There are some features of .pc files that require a minimum version of pkgconfig to support, and older versions mishandle it silently: ./configure of packages that link against libs whose .pc use these features give confusing error messages and/or cause deficient flags to be passed when compiling. Having a having a blanket "must depend" policy causes maintainers (or at least committers) to think about the dependency and decide how/if it needs to be versioned. Con 1: More dependencies==more building for users, and in this case it's of things that aren't "obviously needed" by what user says he wants. Con 2 (Response to Pro 1): pkg-config isn't the only thing that can process .pc files (however, it is the only one in fink at this time). If user wanted to use a different one, why should he also need this one? If fink gets another that is completely backward compatible with the 'pkg-config' program, it would likely supply such a program also, which will lead to a dependency disaster if we have packages that have versioned dependencies on pkgconfi Con 3 (Response to Pro 4): not really...people will blindly add it and not look for any specifics. Would be up to 'fink validate' or responding to user bug reports to handle the the need for versioning. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
