Hackage dependency issues

[Korusuke]

Firstly there are a few packages that are not present upstream but even then declared as dependencies so that should not be added by upt-hackage itself. Example: unbuildable, invalid-cabal-flag-settings, etc..
Do we agree on this? ping @Steap

Then there are ports which are present in hackage but we might not want to mention as dependencies ever like bytestring, unix, win-32, base, etc.. so can we comeup with list of such ports and filter them out and I guess all hackage packages would require ghc....not sure about all this.

ping @mojca @essandess

[essandess]

@Korusuke

I guess all hackage packages would require ghc....not sure about all this.

Not necessarily. They could also require cabal (macports/macports-ports#4715) or stack (macports/macports-ports#4633), which will take care of downloading whatever ghc version is specified in cabal.yaml or stack.yaml.

[Steap]

Firstly there are a few packages that are not present upstream but even then declared as dependencies so that should not be added by upt-hackage itself. Example: unbuildable, invalid-cabal-flag-settings, etc..
Do we agree on this? ping @Steap

Why are these dependencies specified? How are they resolved when Haskell tooling needs them?

[Korusuke]

Why are these dependencies specified? How are they resolved when Haskell tooling needs them?

I am not really sure about this as I have no experience with haskell or hackage but from what I found, invalid-cabal-flag-settings is declared when package doesn't declare flags for base. reference.

unbuildable as per it's cabal file is used to "express impossible build configurations" and from what I notice is used most times to say that the package cannot be build on windows.

[Korusuke]

So how should we proceed with this?