On Fri, Jan 26, 2007 at 01:48:43AM -0500, David Reiser wrote: > Almost exactly 3 years ago there was much discussion about versioning > perl modules. Having read several of those threads, I don't feel so > bad about not understanding. [wrote a new module package...] > I just went and made it versioned (even though I picked the pure perl > version -- text-csv-pp-pm -- because I didn't want to mess with C > code in perl). Do I knuckle down and figure out if it really needs to > be versioned, and fix it if it doesn't? Or can I be slovenly and say, > "I dug this hole, it's not too deep, I can live with it this way"?
I won't tell you how to handle this case, but I'll summarize the policy and my understanding of some of its causes/effects: Any perl module package that (1) contains compiled code or (2) depends on a perl-versioned module must be versioned. All others need not be. Due to #2, best-practice would be to avoid versioning a module unless necessary, since doing so essentially requires that everything that depends on the module be versioned. Also, versioning clutters up the package namespace, which could be confusing/intimidating to users. Switching a module between being versioned and non-versioned (either direction) can be annoying (but not "hard" in most perl-module cases, probably). You would need to have compatibility packages to allow smooth upgrades and/or have to keep the last viable "other format" package around as well as the newer one in the new format. > Second issue: Now that Leopard is out there stalking in the weeds, it > seemed like a good idea to create 588 versions of my modules. That > went smoother than I expected, and they're even all running in > support of my copy of gnucash2. So now, do I modify the gnucash2.info > file to say: Depends: mmm-pm586 | mmm-pm-588, nnn-pm586 | nnn-pm588 > for all the modules? That would almost certainly not work...that says "either mmm", which does not guarantee that it will be the one that matches the perl one is using. That, in a nutshell, is the reason for #2 above. Assuming gnucash runs /usr/bin/perl you could have different forms of the package: one for each distro, each one having the -pmXXX that match the perl that is there. See the intltool package for an example of this approach. Alternately, you could pick a perl you like and adjust the package to use that perl version interpretter specifically on all distros. There will be a perl586 package available in fink on Leopard, just like there's a perl581 package in Tiger for compatibility with Panther's /usr/bin/perl. Lastly, you could write a varianted set of gnucash-perlXXX packages for a bunch of perl versions, and have a bundle "gnucash" that Depends on them. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
