"Daniel E. Macks" <[EMAIL PROTECTED]> writes:
[...]
> 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.
Ok, thanks for your reply. Based on it and what I gathered by looking
at what is being done with python, I have concluded that I need to
proceed as follows:
- make a new package for scsh with the version number explicit in
the package name (e.g. "scsh06"), to replace the current,
unversioned package;
- add a SplitOff called simply "scsh" which only provides the
symbolic links (e.g. /sw/bin/scsh -> /sw/bin/scsh06).
Then I can start providing packages for modules with explicit
dependencies on that specific version of scsh.
[...]
> 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?
I will gladly use whatever you prefer, so unless others disagree I'll
go with your "-sc" suggestion.
The last thing to know is in which section the packages should be put,
although I realise that it's not up to me to take the decision. I've
seen that both Perl and Ruby have their own section, whereas Python
and Emacs extensions are put in various sections, depending on what
functionality they provide. Is one of these solutions officially
preferred now, or not?
Thanks again for your help,
Michel.
-------------------------------------------------------
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
