You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the title is a mouthful but I am wondering if we have a policy for the following situation:
pkg-a (the dependant) depends on pkg-b (the dependency) and on pkg-c <2
pkg-b also depends on pkg-c <2
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.
The text was updated successfully, but these errors were encountered:
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.
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.
Dear Hackage Trustees,
the title is a mouthful but I am wondering if we have a policy for the following situation:
pkg-a
(the dependant) depends onpkg-b
(the dependency) and onpkg-c <2
pkg-b
also depends onpkg-c <2
Clearly, in this situation,
pkg-a
cannot be built withpkg-c==2
.My question is, what if
pkg-a
builds and works correctly withpkg-c==2
whenpkg-b
is patched/replaced/revised to work withpkg-c==2
? Can we revisedpkg-a
to allowpkg-c==2
?For those who don't or cannot patch/replace/revise
pkg-b
,pkg-b
constraint onpkg-c
will be active and preventpkg-a
from building withpkg-c==2
just as before. But those who have the patched/replaced/revised ofpkg-b
will be able to usepkg-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 patchpkg-b
to work withpkg-c==2
. In that case it would have been necessary to also addallow-newer: pkg-a:pkg-c
. I am wondering whether we think this is necesary or can be avoided.The text was updated successfully, but these errors were encountered: