Just to clarify, I guess my confusion comes from Dan's earlier answer: >If config_data has any pathname or versioning information, it's clearly >specific to the XXX, so this forces one to decide which XXX one is >really talking about. For compatibility (such as it is), could use >update-alternatives to install "any once choice" as the simple name. A >perlXXX-core that has this script could also rename it >config_data-X.X.Xcore and join in the update-alternatives pool.
I've read this several times, but I really don't understand it :) To be honest, I really don't care where this file ends up, just want to make sure it is done within fink policies. I took over the package because I needed a newer version for another package and the maintainer back then didn't have time to maintain it anymore. Now this issue was discovered because it turns out conflicts with fink's perl5100. I don't use perl5100 and never added that variant, so never caught it before. - Koen. On 6/21/09, Koen van der Drift <[email protected]> wrote: > > On Jun 21, 2009, at 3:03 PM, Daniel Macks wrote: > > > > > Adding C/R fixes a problem, but not the "conflicts with perl5100" one > > that started this thread. > > > > Ok, then back to my original question, where should the offending file go to > so this issue can be fixed as well? Would /sw/bin/module-build-pmXXX/ work ? > > Thanks, > > - Koen. > > ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org _______________________________________________ Fink-devel mailing list [email protected] http://news.gmane.org/gmane.os.apple.fink.devel
