Re: smlnj blocked from testing. circular dependency
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
Reply to: