Re: Packaging libroadrunner
Hi Kyle,
On Thu, Feb 02, 2017 at 04:59:01PM -0800, Kyle Medley wrote:
> Thanks for your message. I think most of the problems below are due to the
> way libroadrunner handles dependencies. When we build libroadrunner, we
> normally first built static versions of its dependencies, which are kept in
> a separate repository (https://github.com/sys-bio/libroadrunner-deps). Then,
> we build libroadrunner itself and link to the static dependencies. This
> isn't ideal from a packaging standpoint, so I may need to change the way
> some dependencies are found.
>From a Debian point of view "not ideal" is the wrong term - it is just
forbidden by policy. We need to build against existing packages and
nothing else.
> However, there are a few cases where we need to
> link to an old version of a library (e.g. libroadrunner requires LLVM 3.5)
I'm not sure whether it is a sustainable approach to require an outdated
version of a rapidly developing component. Could you be more verbose
why exactly LLVM 3.5 is required and no later version? This might lead
to trouble in the long run also for non-Debian users.
> or need to build a library with certain compiler flags (libsbml must be
> built with namespaces enabled, and requires support for certain experimental
> packages).
May be we should start here and look into the Debian packaging of
libsbml. If it is just adding some flags and enabling packages (may be
in a separate binary package) I'm quite positive that this can be done.
Feel free to clone the libsbml packaging Git[1] and check the build what
changes might be needed. I'd happily add you to the Debian Med team if
you get an Alioth login. So you could directly commit changes to the
packaging code.
> As long as the packaging policy does not prevent us from
> depending on these old or specially-built libraries, I should be able to
> package libroadrunner.
Sorry, that's not possible, but I consider it a good idea to consider
making libroadrunner more flexible about dependency versions.
> As for the libstruct project, I think the original maintainers have moved on
> but I would be happy to package it for Debian.
>From the perspective of relying on a specific version it can be
practical if the authors moved on and no new version is to be expected.
;-) So, yes, it might be a good idea to start with libstruct if you
have a link to the latest source code release.
> Also, I concur with your
> suggestion regarding joining the Debian Med packaging team. I will try to
> look into that as soon as I can.
Good. Just create an account on alioth.debian.org and make sure you follow
the "SSH tips" in Debian Med policy[2] closely as in the linked Wiki page
specified. (Just mentioning it since I recently experienced some failures
to login since the user did not followed exactly ;-) )
Than we can move on and I'd happily support you in libroadrunner
packaging. As far as I can see users might be happy to get a packaged
version since getting the preconditions done seems not to be trivial.
Kind regards and thanks for your cooperation
Andreas.
[1] https://anonscm.debian.org/git/debian-med/libsbml.git
[2] https://debian-med.alioth.debian.org/docs/policy.html#ssh-tips
--
http://fam-tille.de
Reply to: