On Wed, Jan 15, 2003 at 01:02:20AM -0500, Matthew Danish wrote: > Are these SML/NJ specific? It might be a good idea to prefix them if > they are. Even if they are not, perhaps an sml- prefix would be in > order, much like CL packages are prefixed with cl-. A crude > namespacing, but it could help. It's debatable whether non-development > related applications should have the prefix, but libraries and whatnot > should. I think adopting a policy similar to the ocaml one would be best, I am currently studying their docs. It would be nice to get the sml packaging up to the quality of ocaml.
> One thing you might want to think about is how to play nice with future > versions. In other words, if a future version's runtime is not > backwards compatible then you will have to arrange a separate package > with separate directories. Possibly even a package name with version > information, if you want to be able to have both versions installed > simultaneously. sml-nj-runtime110.42, etc. I have spent some time thinking about this over the last couple of days. I like this idea very much, but the main problem that I would like some guidance on the best way to achieve this, since the upstream maintainer does not use major/minor version numbers to indicate which versions of the runtime would be binary compatible. One way might be to assign an epoch to a series of runtimes that were compatible, such as smlnj0-runtime for versions of the runtime compatible to the current, and incrementing when they release the next incompatible runtime. Under such a system, how would /usr/lib/smlnj best be divided? Perhaps as subdirectories named with the epoch compiled against such as smlnj0? > One little thing: why smlnj instead of sml-nj, as before? The new packaging is based on work done by Christopher League in his Fink package. We are collaborating on this new packaging. His packages were called smlnj, rather than the sml-nj name that was used in Debian. I have grown to like it. Also, it seems that under a new naming scheme for libraries, it would be best to avoid extraneous hyphens, and save the for where they make sense. But at the same time, perhaps it would make sense to go back to the old scheme, using "sml-nj" for the compiler package, to achieve better continuity between the old packaging and the new. I don't really like the idea of introducing a "sml-nj" dummy package unnecessarily. -- Aaron Matthew Read <[EMAIL PROTECTED]> http://www.nyx.net/~amread