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

Re: ANN: cabal-debian et el

"Jeremy Shaw" <jeremy@n-heptane.com> writes:
> Trent W. Buck wrote:
>> "Jeremy Shaw" <jeremy@n-heptane.com> writes:
> The number one thing I use cabal-debian for is to debianize packages
> from hackage for local use only. Meaning, I just build and install
> them on my machine, I don't actually upload them anywhere.

A good point, though arguably if you were doing this for >>1 machine,
it'd be worth your while to set up a private package archive, which
would mean that you had a Contents file for those packages.

>> It seems reasonable to me for cabal-debian to require that apt-file be
>> installed and up-to-date, than to require all the build-dependencies to
>> already be installed.
> [...]  However, I think the solution to all these problems is to do:
>  1. first try to map the cabal package name to a binary deb name based
>     on locally installed packages.
>  2. if no match is found, try searching the Contents files.
>  3. if no match is found, use the debian haskell policy to guess the
>     correct name (and issue a warning).

That suits me.

> However, there is another problem that has to be solved if the cabal
> package is not actually installed locally. How do you know what file
> to search for?

That I do not know.

> Let's say foo depends on bar > 3 && bar < 4. When bar is installed
> locally, we can ask cabal where the files for the package that meets
> those dependencies lives. But, if bar is not installed, then we need
> some other way to derive that information.

Can you make a reasonably accurate heuristic based on Debian Haskell
policy?  As long as it doesn't return false positives, you can still
fall back on case (3).

Reply to: