About pushing the Debian packaging into Debian

[frediz]

Hi Paul / all,
I'd really be happy to see mercury in Debian again especially to package my favorite mail software "bower" coded with the mercury language.
mercury used to be packaged in Debian : https://tracker.debian.org/pkg/mercury but it finally got removed :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538802
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446665

I see that recently the package has been updated to be used in sid (I just haven't tested it yet now)
Though, there's no newer release than the 2014 one.

What do you think of this possibility ?
Do the reasons why mercury got dropped from Debian still exist ?
If not, what are the blocking problems ?
And are there any plans to solve them and go in that direction of Debian upstreaming ?
Thanks a lot for your time,

F.

[PaulBone]

Hi,

The short answer is that I am interested on working on these packages further, but probably not motivated enough to actually attempt to get them into Debian. However if someone else wants to do that I'm more than happy to provide advice and assistance as I can.

The more detailed answers are:

I see that recently the package has been updated to be used in sid (I just haven't tested it yet now)
Though, there's no newer release than the 2014 one.

Those aren't stable releases and I guess Debian won't be interested in them. According to bower's README.md it only needs a 2011 version or greater. So the 2014 version should be fine.

I do hope to package a more recent version, but this is more-or-less to make my own life easier.

The newer Mercury versions tend to have better support for newer GCC versions, so even though there's no stable release in the last few years, it would be helpful to package one of the snapshot versions.

What do you think of this possibility ?

I think that it is possible and good. There are a few minor issues that will make it more difficult / bend normal packaging conventions. The big ones I can think of right away are:

1. Self hosting.

This may be an issue, my debian package will build itself from the C files, in the source package, then bootstrap itself from that version. I think this is the best option but Debian maintainers may want to ask some questions about that.

2. No proper shared library versioning.

This creates two problems, the first is that upgrading a Mercury .so file can easily break other Mercury programs. Either we could use static libraries exclusively or when using shared libraries other package authors (like bower) would need to add a dependency to a specific Mercury shared library version, as I have done with the Mercury packages themselves.

This also means that all packages that depend on Mercury shared libraries would need to be upgraded/updated at the same time, or cannot be installed concurrently.

The other problem this creates is that you cannot use multiple Mercury versions concurrently. Which could be a drag for anyone wanting to use the stable version most of the time, and then try some new features ion the snapshot version (ROTD). It would also cause a lot of confusion to put them both in the same Debian package repository. They would need different names so you don't automatically upgrade to an unstable version. And yet Mercury releases arn't frequent enough for a lot of user's needs.

So I think it can be added to Debian, doing so will be good, but perhaps difficult. Adding proper versioning to Mercury's shared objects may also be difficult, eg: I don't think anyone has tried defining a formal API/Interface to the runtime library and made it clear what is part of that interface and what isn't. Then there's the Mercury ABI itself, changing a data-structure such as MR_Context (although not user visible) can break binary compatibility. (Mercury does attempt to refuse to link if the developers who change such a structure increment a certain version number).

Do the reasons why mercury got dropped from Debian still exist ?

This came from when the package was removed (your 3rd link above):

Your package came up as a candidate for removal from Debian, because:

• 4 RC bugs opened for a long time.

Those 4 problems have probably been fixed by now, now there are probably 4 totally different problems :-).

• not suitable for a stable release according to #281369

That bug report has very little information, but AIUI it's some of the same stuff as above.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=281369

• Low popcon (19 insts)

Yeah, that'll probably always be true.

• Hasn't been in testing for a very long time

Now irrelevant.

• New upstream release available for a long time now

And even newer versions now!

If not, what are the blocking problems ?
And are there any plans to solve them and go in that direction of Debian upstreaming ?

I think ti's just a bunch of work for someone to volunteer for. I have no plans to do this myself.