Re: SML-NJ Package Names
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
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
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@example.com> http://www.nyx.net/~amread