[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packing Matreshka for Debian



On Fri, 9 Nov 2018 14:12:55 +0200, Maxim Reznik wrote:
Hello,

I'm trying to pack Matreshka[1] library on Debian/Ubuntu.
Matreshka has several libraries and executables (about 20). I've
started with League library, because it's core part of Matreshka.

I put the first version of the package to Ubuntu PPA[2] to be able to
ask for advice. In some place I didn't follow Ada Debian Policy:

 * I don't provide static libraries, because "upstream" doesn't
provides it neither

The requirement for static libraries has been lifted in recent
editions of the Debian Policy so we can accept that in the Debian
Policy for Ada.

 * There is some mess related to names:
 ** project file is matreshka_league.gpr and I would prefer to keep
this name to compatibility with other distros
 ** but library is libleague*.so and package names are libleague*.so
and directories in ada/include/ and ada/adalib/

Upstreams and distros that do not have a sound and consistent naming
policy are their own problem, not for Debian users to put up with.
The purpose of the Debian Policy for Ada is to enforce consistency.
Therefore you must provide league.gpr and only this in libleagueX-dev,
even if upstream is inconsistent.

However, you may provide an additional package named
libmatreshka_league-dev, providing matreshka_league.gpr as a symlink
to league.gpr.  Of course libmatreshka_league-dev must depend on
libleagueX-dev.  This package can go away if and when upstream becomes
consistent in their naming.

 * in binary package libleague-7.3.so.18.1 saved in
/usr/lib/x86_64-linux-gnu/ada/adalib/league (where gprinstall puts
it), but there is a link in /usr/lib/x86_64-linux-gnu/

/usr/lib/x86_64-linux-gnu/ada/adalib/league violates the policy; do
not include it at all in the -dev package.  If gprinstalls places
the shared library file where it shouldn't, then it's a bug in
gprinstall or (more likely) in the project file used by gprinstall.
The purpose of debian/rules is to fix this kind of bug for Debian,
enforcing consistency, so you don't have to fix the upstream
project file; merely work around it in debian/rules.

Is it critical enough to prevent inclusion in Debian/Ubuntu?
What do you suggest?

Dura lex, sed lex. If you want your package to be accepted in Debian,
you must abide by both the Debian Policy and the Debian Ada Policy.

--
Ludovic Brenta.

--
Ludovic Brenta.


Reply to: