Re: [Fink-devel] module-build-pm5100-bin conflicts with perl5100

2009-06-29 Thread David R. Morrison
On Jun 29, 2009, at 2:18 AM, Daniel Macks wrote: > On Sun, Jun 28, 2009 at 09:29:21PM -0700, David R. Morrison wrote: >> >> Actually, /sw/bin/config_data is perfectly appropriate, since only >> one module-build-pmXXX package should be installed at a time. >> >> The only problem here is that the p

Re: [Fink-devel] module-build-pm5100-bin conflicts with perl5100

2009-06-29 Thread Koen van der Drift
There are now two threads going on about this subject, one in -core and one in -devel. Since I don't belong to -core, I'll follow up here. On 6/29/09, Daniel Macks wrote: > We really need to figure out whether config_data is used directly by > users (i.e., must be in PATH so can run as command) o

[Fink-devel] libgda3 vs libgda4 (conflict)

2009-06-29 Thread Alexey Zakhlestin
Both gnome/libgda.info and gnome/libgda-3.1.5.info provide "libgda" package. Something should be done to distinguish those. -- Alexey Zakhlestin http://www.milkfarmsoft.com/ -- ___

Re: [Fink-devel] module-build-pm5100-bin conflicts with perl5100

2009-06-29 Thread Daniel Macks
On Sun, Jun 28, 2009 at 09:29:21PM -0700, David R. Morrison wrote: > > Actually, /sw/bin/config_data is perfectly appropriate, since only > one module-build-pmXXX package should be installed at a time. > > The only problem here is that the perl5100 package Provides module- > build-pm5100-bin,

Re: [Fink-devel] module-build-pm5100-bin conflicts with perl5100

2009-06-29 Thread David R. Morrison
On Jun 20, 2009, at 10:34 AM, Jean-François Mertens wrote: > Hi Koen ! > >> Unpacking module-build-pm5100-bin (from .../module-build-pm5100- >> bin_0.33-1_darwin-i386.deb) ... >> /sw/bin/dpkg: error processing /sw/fink/dists/unstable/main/binary- >> darwin-i386/libs/perlmods/module-build-pm5100

Re: [Fink-devel] graphviz-nox prospects

2009-06-29 Thread Alexander Hansen
David Fang wrote: > There will be no dependencies between graphviz variants. graphviz-base > (whatever we name it) will have to conflict/replace other sibling > variants *unless* there is an easy and reliable way to separate out a > plug-in-only build/package (not via split-off b/c that would sti