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

Re: Dh_Haskell's configure recipe datasubdir

On 2015-05-30 23:00:47, Joachim Breitner wrote:
> Hi,
> Am Samstag, den 30.05.2015, 19:32 +0200 schrieb Iustin Pop:
> > I see that Dh_Haskell's configure_recipe pases this to the configure:
> > 
> >         --datasubdir=${CABAL_PACKAGE}
> > 
> > If I understand things correctly, without overriding datadir, this
> > results in Haskell packages using paths directly under /usr/share
> > based on the cabal package name, which is the not the debian package
> > name, hence /usr/share mixes two namespaces.
> > 
> > Normally it might not be a problem, but for some Cabal packages with
> > common names like js-jquery, it means we steal or conflict on a very
> > generic name.
> > 
> > Does anyone know the rational of using CABAL_PACKAGE instead of the
> > actual package name (which should prevent any conflicts)?
> the rationale of that flag is to not encode the version number in the
> path. For most packages, using the Cabal name is the right thing, as
> most packages that ship such files have non-generic names (shake,
> pandoc, hlint).

Not sure I'm convinced. In case of pandoc and hlint, the debian packages
for the binary match the cabal package name, so they could be argued
either way.

In case of shake, looking at the contents of libghc-shake-data, it seems
we "stole" /usr/share/shake from the actual shake package (Testing
engine for the Lua language version). So we already have a problem with

The debian policy (section 8.2) also recommends to use "package-name" as
a subdirectory of /usr/share. So:

> If we have packages with a generic cabal name that put stuff there then
> we need to extend haskell-devscript to allow us to change that flat.
> Patch welcome :-)

I'd rather prefer that we change the default to be either the source
package name or one of the binary package names. The code shouldn't care
about what the name of this directory is, but it seems it would be safer
to use a non-conflicting one, always.

In the meantime, I can fix this for js-jquery by overriding
DEB_SETUP_GHC_CONFIGURE_ARGS, so it's not any immediate problem.


Attachment: signature.asc
Description: Digital signature

Reply to: