search

haskell-infra / hackage-trustees

Issue tracker for Hackage maintainance and trustee operations
https://hackage.haskell.org/packages/trustees/
42 stars 7 forks source link

Do bounds in a dependency have to propagate upward to the dependant? #359

Open andreabedini opened 1 year ago

andreabedini commented 1 year ago

Dear Hackage Trustees,

the title is a mouthful but I am wondering if we have a policy for the following situation:

Clearly, in this situation, pkg-a cannot be built with pkg-c==2.

My question is, what if pkg-a builds and works correctly with pkg-c==2 when pkg-b is patched/replaced/revised to work with pkg-c==2? Can we revised pkg-a to allow pkg-c==2?

For those who don't or cannot patch/replace/revise pkg-b, pkg-b constraint on pkg-c will be active and prevent pkg-a from building with pkg-c==2 just as before. But those who have the patched/replaced/revised of pkg-b will be able to use pkg-a the way it is without relaxing more constrinats.

This is basically the situation behind #358. Note that I don't think this is necessarily a IOG specific problem, developers could have been vendoring pkg-b in their projects to patch pkg-b to work with pkg-c==2. In that case it would have been necessary to also add allow-newer: pkg-a:pkg-c. I am wondering whether we think this is necesary or can be avoided.

endgame commented 1 year ago

I personally expect packages to only claim bounds of things that they actually build with. In your example, if pkg-a depends on pkg-b with patches that don't end up making it to the next pkg-b release, you could be in strife.

This seems much less likely to be a problem if you're only talking about bound revisions, but then it's much easier to just to fix the bounds bottom-up, relying on fixes that are actually present on Hackage.

EDIT: I'm not aware of any specific policy about this.

andreabedini commented 1 year ago

I personally expect packages to only claim bounds of things that they actually build with. In your example, if pkg-a depends on pkg-b with patches that don't end up making it to the next pkg-b release, you could be in strife.

In the case I am referring to, pkg-a does depend on pkg-c directly. Indeed pkg-a uses pkg-c in a way compatible with both version 1 and 2 while pkg-b uses pkg-c in a way that is only compatible with version 1.

phadej commented 1 year ago

But those who have the patched/replaced/revised of pkg-b

... can patch pkg-a bounds too.