On Tue, Nov 30, 2004 at 06:33:21PM -0800, Steve Langasek wrote: > The sml-nj package is related to the problem, but it has nothing to do with > what's in testing. Is there a reason for the name change of this package? > If the sml-nj package is done, you should request its removal from unstable > by filing a bug against ftp.debian.org.
'sml-nj' was my first Debian package, so try to forgive all the rookie mistakes in this short history of the package: 'sml-nj' was part of Debian but was eventually dropped because it was too hard to package. As my first effort in packaging it, I reused the name 'sml-nj'. Shortly thereafter, someone contributed their own packaging that used the name 'smlnj'. This seemed a better name to me so libraries could have sane names without too many dashes so I adopted it, and used the package 'sml-nj' to recommend the entire sml/nj distribution (which seems stupid in retrospect). The goal of this packaging was to create a joint Fink/Debian package, so I tried to eschew the use of debhelper and had everything as separate source packages (including 'sml-nj'). Later I did a major overhaul where 'sml-nj' became part of the 'smlnj' source package. Then sometime later I gave up on the Fink/Debian idea and started using debhelper and the package came to its current state where everything is built from one source package. I realized at that point a 'sml-nj' catchall package was a dumb idea, so I dropped it. There is a #235407 against the 'sml-nj' source package, should I file one against the binary package as well? > The current status is that there are lots of smlnj and sml-nj binaries of > different versions in unstable, and the archive scripts can't sort out which > binaries belong to which source packages. For that matter, neither can I at > a glance; but it seems that at least one version of the smlnj source package > was uploaded that produced an sml-nj binary package, so I think the old > sml-nj source package will need to go from unstable before this can be > cleared up. All sml-nj packages should go away. > Er, you don't *have* to always upload the newest upstream version? I'm a little confused by the question mark. I would like to provide users with current packages, but I would rather have a newer version of the package in testing, as the quality of the packaging is much better than in the 110.44 version. Aaron
