well if this is the case it's a very easy thing to lift form my dpkg 1.16.3 patch, and like I posted I could currently turn it into a warning so we are notified?
Currently my patch in exp does like the 1.10 patch and just assumes 0-0 is good, but I due agree this isn't best it's just how it currently is. You guys are the boss so once core know what they want I'm happy to help get it there. --- TS http://www.southofheaven.org/ Life begins and ends with chaos, live between the chaos! On 2012-07-02, at 11:55 AM, Daniel Macks wrote: > 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 ------------------------------------------------------------------------------ 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
