On Sun, 01 Jul 2012 21:59:43 +0200, Sjors Gielen <sj...@sjorsgielen.nl> wrote: Op 01-07-12 21:54, TheSin schreef: > > would we rather it silently do it or with a warning but still pass? > I assume no warning but thought I'd show an example. > > > justin@tracer [/sw/fink/dists/local/main/finkinfo]$ sudo dpkg -i > /sw/fink/debs/test-simple-pm5123_0.98-1_darwin-x86_64.deb > (Reading > database ... 195742 files and directories currently installed.) > > Preparing to replace test-simple-pm5123 0.98-1 (using > .../test-simple-pm5123_0.98-1_darwin-x86_64.deb) ... > > Unpacking replacement test-simple-pm5123 ... > > dpkg: test-simple-pm5123: dependency problems, but configuring > anyway as you requested: > > test-simple-pm5123 depends on test-harness-pm5123 (>= 3.21-104); however: > > Version of test-harness-pm5123 on system is 0-0. > > Setting up test-simple-pm5123 (0.98-1) ... > > That depends on whether we want to move to a different system. I think > depending on the correct version of the Perl module is a good thing, so > it depends on whether we want fink-virtual-pkgs to set the correct > version number for Perl modules (for example, by loading it then > checking $VERSION). If we intend to write such a patch, this warning > might be a good reminder to do this at a certain point. Otherwise the > warning is just silly and annoying, and trains people to ignore warnings > in dpkg...
We definitely don't want to blindly assume that "have a provided module, therefore it's good enough version" (ignoring the version)! Most perl-modules are "dual-lifed" and exist on CPAN independently and develop and release on their own (!= perl-core) cycle. If a package says "foo-pmXXX >= 2.0" and perlXXX-core only has it at 1.0, fink should be looking to install an actual foo-pmXXX package of at least version 2.0, not accept the 1.0 in perl core. If a package really doesn't care what version of foo-pmXXX it gets (or it knows that the ones in perl core are good enough) the maintainer can simply not bother specifying the version. If a dependency really is satisfiable by perl core, there's no need to specify the dependency at all. At worst, specifying the version forces users to install the dual-lifed independent package in the cases where perl core's is good enough. An alternative would be to look up what perlXXX-core have the minimum version needed and have those variants not specify the dependency (since the dependencty on perlXXX-core will obviously be sufficient), only explicitly specifying it on the lower ones (where perlXXX-core is not and user would need to have the separate package installed regardless).Regarding detecting the versions to provide dynamically, that's...pretty expensive, and becomes fragile as soon as a user installs a nonstandard module or perl-core that overwrites anything standard. More self-consistent would be to haul Module::CoreList into fink-core. It's a giant hash that hardcodes the known module-versions of all perl-core modules in all perl-versions.On the other hand, this whole idea is a non-starter as soon as we start packaging our own perl interps (which is where we seem to be headed with the 10.[78] shared distro and not wanting to block the ability to have newer perlXXX-core ever in the future). That's because perlXXX-core could be a package, not a data structure that Fink::VirtPackages can forge to its liking. The general idea of versioned provides sure is interesting, but special-casing it in f-v-p in a way that isn't really applicable to other places one might want it seems like we're setting up a maintence mess for the future. dan -- Daniel Macks dma...@netspace.org ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
