[m-dev.] Re: mercury: should this package be removed?

[Paul Bone]

On Tue, Feb 19, 2008 at 03:27:37PM -0500, Barry deFreese wrote:
> Hi folks,
> 
> Sorry for all of the CCs but all of you have expressed interest in 
> fixing/adopting this package (with the exception of QA).
> 
> Do any of  you still have an interest and/or a plan to fix this 
> package?  According to the Mecury website, it is supposed to build with 
> gcc-4.1 which would be a hell of a lot better than gcc-3.x.
> 
> Is that not the case?  This thing has been orphaned a while and has an 
> RC bug over a year old.  If no-one wants to fix it up, I will request 
> removal within the week.
> 
> If I can help with packaging or fixing this thing, please feel free to 
> contact me and will gladly help if I can.  Otherwise it's a goner. :-)
> 

Hi Barry.

I'm interested in re-packaging this, however it's going to be one of
those things that gets a small amount of attention here and there.  I'm
one of the Mercury developers, so I use and develop on Mercury
day-to-day.

The Mercury website should be considered correct, this package (in
debian) is a very old version of Mercury and I'd like to release a newer
package based on the current stable version, and also ensure I can
produce .debs for the current CVS HEAD.

There are several components to mercury that I'd like to package in
seperate binary packages.  These are:
    + Complier
    + Runtime and Standard Library
    + Other tools such as debuggers and profilers.

Mercury also supports 'grades', this makes it different to other
compliers and more interesting to package.  Each grade represents a
complier backend and some options.  There are two C backends, a Java
backend, and Erlang backend and a MSIL backend.  Options can include
optional garbage collection (as apposed to never reclaiming memory),
profiling support, debugging support and more.

I'd like to package the library and runtime for each grade.  These can
all be installed concurrently and won't conflict.

This will mean that there may be 6-12 mercury-related packages.  And
since I haven't packaged for Debian before this is rather an ominous
task.  I intend to read plenty of documentation and seek the help of
debian-mentors at debian.org as appropriate.

I usually use the ROTD releases, however that's mostly because I'm
working on Mercury it's self.  It is probably useful to package a stable
release and a ROTD, since we havn't made a release for a while.

Unfortunatly I can't make any progress of when this will be done, and
I'm not yet sure the best way to do it.  Will removing the old package
from Debian make it harder for me to get this one in?  If so I'd like it
left in Debian until I'm able to complete this.  But since I want to
package the new stable version instead removing it may not affect me.

Ray Ward:  I'd like to addopt this, may I?  If you agree I'll change O
to ITA and make myself the owner on bug #379682.

I've also CC'ed the mercury-developers at csse.unimelb.edu.au mailing list.

Thanks.


--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------