On 26 Jan 2007, at 2:14:36 AM, Daniel Macks wrote: > 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.
It turns out I got it right by accident -- text-cvs-pp-pm's only builddepends, (test-simple), is versioned. > >> 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. The haze is clearing a little more.... Thanks for the help. > > dan > > Dave -- David Reiser [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
