Re: Why is package X not in testing yet?
Hi Sven,
Thanks a lot for taking the time to look at comigrate!
On Tue, 19 Aug 2014 12:45:59, Sven Bartscher wrote:
> On Mon, 18 Aug 2014 23:51:43 +0200
> Pietro Abate <Pietro.Abate@pps.univ-paris-diderot.fr> wrote:
>
>> Hei Sven,
>>
>> On 18/08/14 18:10, Sven Bartscher wrote:
[...]
>> you might want to have a look at comigrate [1] a tool designed to
>> answer these kind of questions and provide explanations that are as
>> compat as possible. For example for haskell-hgettext [2] . If you find
>> it useful, I'm sure the authors would be happy to hear from you.
>
> I looked at it and it's a great tool to identify problems with
> migrations, but it's not really what I was aiming for when I wrote my
> tool.
>
> The web interface does list that haskell-src-exts needs to migrate,
> which is right, but not really helpful. To find the root causes of the
> problem I need to navigate through all the packages with their own
> listings. If my browser wouldn't mark links I already visited I would
> have a great chance to end up in a loop.
> So it's just too much data to understand what's the problem and what to
> do against it.
You are correct that the Web interface is not really appropriate to
analyze large transitions.
> The command line interface couldn't provide as much information. It
> follows the dependency chain until it ends up at pandoc and doesn't
> know what to do.
The command line interface is meant to be used interactively. Here, the
tool tells you that haskell-hgettext cannot migrate as this would break
package libghc-pandoc-dev. You can decide that its fine to break this
package (for now) by adding '--break libghc-pandoc-dev' to the command
line, and then run the tool again to find other issues. Alternatively,
you can tell the tool to do as if the package pandoc was removed from
unstable by using the '--remove pandoc' directive.
The --break directive is useful to find issues when preparing a
transition. The --remove directive is most useful at the final stage, to
see which broken packages have to be removed from testing for the
transition to take place.
By iterating, you can find all issues reported by your tools, and more.
This is tedious when there are many issues, so maybe that could be
automated somehow.
> My tool (which still doesn't have a name, suggestions welcome) has
> another approach of identifying the problem. Instead of checking
> dependencies it checks for the autohint the package in question is in.
> So instead of searching for the relevant information itself, it takes a
> huge amount of information and filters it for the useful informations.
>
> Wile this approach gathers more relevant information than other tools
> (I know), I still don't know if it identifies all issues a package
> might have.
As far as I can see, for haskell-hgettext, it misses some dev and prof
binaries from the following packages that needs to be recompiled:
haskell-active, haskell-authenticate-oauth,
haskell-diagrams-cairo, haskell-diagrams-core,
haskell-diagrams-gtk, haskell-diagrams-lib,
haskell-diagrams-svg, haskell-esqueleto, haskell-github,
haskell-hakyll, haskell-happstack-heist, haskell-hledger-lib,
haskell-hledger-lib-prof libghc-http-conduit,
haskell-hxt-tagsoup, haskell-hxt-xpath, haskell-hxt-xslt,
haskell-osm, haskell-pandoc-citeproc, pandoc,
haskell-persistent, haskell-persistent-postgresql,
haskell-persistent-sqlite, haskell-persistent-template,
haskell-pipes-attoparsec, haskell-regex-tdfa-utf8,
haskell-snap, haskell-snaplet-acid-state, haskell-unixutils,
haskell-vector-space, haskell-vector-space-points,
haskell-xml-hamlet, haskell-yesod-auth-account,
haskell-yesod-auth-oauth, haskell-yesod-persistent,
haskell-yesod-static
Some of these packages depend on other out of date packages. For
instance, libghc-unixutils-dev depends on libghc-regex-tdfa-dev. I
understand why this package is not listed: your tool has no way to know
that recompiling libghc-regex-tdfa-dev is not going to be sufficient.
But your tool also misses binary package dependency issues, which are
not listed in Britney's excuses. For instance, it does not see that
libghc-pandoc-dev needs to be recompiled. I don't see how to fix that.
You could look at the autohinter failure output, but you are going to
get a lot of false positive if the hint is not quite correct. In the
case of haskell-hgettext, there should be no failure on the i386
architecture, for instance, but package yi and several others packages
are missing from the hint.
Regards,
-- Jérôme
Reply to: