installing internal library with Cabal and "cabal install" gives different id's

[juhp]

I tried to install haddock-library with Cabal-2.2.0.1 and got:

haddock-library-1.5.0.1-919WkNWGnku6Kvc4vlhbv1-attoparsec.conf
haddock-library-1.5.0.1-DfHt27RGS18LxLALgHOunK.conf

This behaviour is pretty bad for distro packaging. :-(

When I install with cabal-install-2.2.0.0, I got:

haddock-library-1.5.0.1-1JAUuIjfe1t2Y9APYsRkwa-attoparsec.conf
haddock-library-1.5.0.1-1JAUuIjfe1t2Y9APYsRkwa.conf

cc (opensuse guys) @peti @mimi1vx

(And sorry I feel compelled to moan: I think internal sublibraries are a really bad idea.)

[23Skidoo]

/cc @ezyang

[ezyang]

I think this is expected behavior, but you can work around the problem by explicitly passing an --ipid to be the value you want the random string to be (and it will consequently be generated deterministically in the way you want.)

I want to explain this in a little more detail.

First, as a distro packager, you are under no obligation to use the IDs that Cabal generates. Indeed, for distro packaging, it is recommended that you feed your own IDs during the configure process; this is what the --ipid flag does. For example, when cabal-install generates IDs, it overrides Cabal's default algorithm and allocates all of the IDs according to the new-build algorithm.

Second, the reason the IDs diverge is because Cabal is trying to be "clever" and only feed in "true" dependencies into the hash. The hash is identified to help you identify when you have two packages that are the same version, but built with different dependencies. Clearly, haddock-library's ID should be computed based on the dependencies of haddock-library. But the sub-library, attoparsec, doesn't necessarily have binary dependencies which are the same as haddock-library; indeed, it will usually have less. So, in an attempt to be "clever", we gave it a separate hash. However, I don't think anything really relies on it, so if you really hate this default we can definitely change it.

Third, you commented that "I think internal sublibraries are a really bad idea." I assume this is because internal sublibraries complicate the mapping between Cabal packages and distribution packages. I have come around to the thinking that every internal library SHOULD get its own binary package (the situation only gets worse with Backpack; atomizing packages into multiple packages seems like the only way to make it work). And so there are new APIs in Cabal for building components individually, so that the traditional distro model "you run a build script and then out pops a distro package" still works.

I know distro packaging teams are overworked and want things to "just work", so you should try the --ipid thing first, but I wanted to point out that Cabal has tried to make this workflow work. I'm happy to chat more about specifics if you are interested.

Hope that helps, and sorry about the frustration.

[juhp]

Thanks Edward for the explanation - that makes some sense I see. (I just got back from some travel.)

I will try to play more with it later when I have time, particularly --ipid. If there was a simple way to get Cabal and cabal-install to behave the same way that would be ideal in my opinion.

[ezyang]

Yeah, the best way is to see what Setup flags cabal-install is passing to Cabal, and pass them yourself.

[juhp]

Yes, I see cabal-install using --ipid but I don't see how to calculate the hash easily: I should look how cabal-install does it.

[ezyang]

I should emphasize that the value of --ipid is an application specific setting: if you're the distributor, you get to decide what it is. For example, if your distro decides that there should only one copy of any package, you can set --ipid=packagename, fullstop.