Michel Schinz <[EMAIL PROTECTED]> said: > > scsh is a scripting language similar to Perl/Python/Ruby/etc. for > which some libraries, which I'll call modules below, exist. [reordering some paragraphs] > The first problem I have is one of dependency. It happens that scsh > modules are installed in directories which explicitly refer to the > major and minor versions of scsh to which they belong, e.g.: > > <prefix>/share/scsh-0.6/modules/<module-name>/scheme > ^^^^^^^^ > where <prefix> is the prefix given at installation time (would be /sw > for Fink) and <module-name> is the full name of the module, including > its version. > > Since this directory (and the code it contains, in fact) is specific > to scsh 0.6 and is not expected to work with scsh 0.7, I'd like to > specify that in the "Depends" field. But I'd also like to specify that > the version of scsh has to be greater or equal to 0.6.6, [modules are only supported starting in 0.6.6] > The following seems to work, but I wonder if there's a cleaner way: > > Depends: scsh (<< 0.7.0), scsh (>= 0.6.6)
This is the same problem we have with perl (etc.) modules, and other types of things that are associated with a package that is binary- incompatible (due to API/ABI or file location) in different versions. The solution in those cases is give the interpretter package a name that includes this major version information. Since each module is specific for a certain interpretter version, this means one has each module Depends on the desired interpretter. For example, instead of "scsh", you would have "scsh6" and "scsh7", and then modules named "foo-sc6" (Depends:scsh6(>=0.6.6)) and "foo-sc7" (Depends:scsh7). If you install the interpretter itself as bin/scshX instead of bin/scsh (and maybe optionally provide a bin/scsh->scshX symlink, again as with python and perl), users could have both present at once, to make version-migration and upgrading easier. Otherwise, one could not change scsh version unless one also updated *all* module packages at the same instant...that sounds like a user-upgrade and package-maintainer nightmare. > The other problem is one of naming. Since I expect that in the long > run there will be quite a lot of Fink packages for scsh modules, maybe > I should name them in some consistent fashion, or even put them in > their own section. Any suggestion in that respect? Other language-module packages have an extension denoting the language (-py for python, -pm for perl, -el for emacs/lisp, etc.) Maybe "-sc" for scheme? dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
