Common .cabal file handling in hs-ports

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Common .cabal file handling in hs-ports

Greg Steuck
Hi Matthias,

I noticed we have a few bound relaxation patches that approximate the
cabal behavior of downloading revised package files from hackage. I
propose we build a tiny bit more common mechanism into ghc.mk that
would copy files/*.cabal files if they exist over into $WRKDIST. Then
we can replace a few patches with copies of complete files from
hackage that their authors submitted.

If this sounds good I'll figure out which ports we can clean up this way.

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

Reply | Threaded
Open this post in threaded view
|

Re: Common .cabal file handling in hs-ports

Matthias Kilian
Hi Greg,

On Sun, Feb 23, 2020 at 08:37:03AM -0800, Greg Steuck wrote:
> I noticed we have a few bound relaxation patches that approximate the
> cabal behavior of downloading revised package files from hackage. I
> propose we build a tiny bit more common mechanism into ghc.mk that
> would copy files/*.cabal files if they exist over into $WRKDIST. Then
> we can replace a few patches with copies of complete files from
> hackage that their authors submitted.

I don't understand the benefit of complete copies of .cabal files
over patches.

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.

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.

> 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?

Ciao,
        Kili

Reply | Threaded
Open this post in threaded view
|

Re: Common .cabal file handling in hs-ports

Greg Steuck
Hi Matthias,

On Sun, Feb 23, 2020 at 11:50 AM Matthias Kilian <[hidden email]> 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