Hi Matthias, On Sun, Feb 23, 2020 at 11:50 AM Matthias Kilian <k...@outback.escape.de> wrote: > I don't understand the benefit of complete copies of .cabal files > over patches.
I was hoping to get some automation around it, but maybe the change should wait until such automation materializes. > IMHO, the annoying part when updating a hs-port (or writing a new > one) is, that after a build failure caused by too strict dependency > constraings, you'll have *always* to look wether there's a "revised" > package description available, and, if so, adopt the changes to the > port -- wether you do so in form of a patch against the .cabal file > in the DISTFILE or by copying the rvised .cabal file to files/ > doesn't look like a big difference to me. This is somewhat automation-friendly. I can think of a special target (update-cabal) that would download the most recent cabal file. Luckily they have very predictable URLs. > There's also the risk of forgetting to remove a .cabal file from > files/ when updating a port to a newe version. When you forget to > rm a patch against a .cabal file, you'll end up with a conflict > during make patch. With the files/ approach, you would probably end > up with weird build failures. That's fair, some kind of grep-guard could take care of it. > > If this sounds good I'll figure out which ports we can clean up this way. > > I had a quick look with ls */*/patches/patch-*_cabal. There are 25 > patches against .cabal files (not counting the one in lang/ghc). > Not all of them contain constraints changes only. Is it really worth > the (potential) trouble for such a relatively low number of ports? The answer in part depends on the prevalence of revised cabal files in hackage. The other part would be how many of these are we likely to import any time soon. Thanks Greg -- nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0 Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
