Mark almost all Haskell ports for expiration.

[arrowd]

Summary

Ports for Haskell libraries are going to be removed from the ports tree.
Haskell applications are going to be statically linked with all dependencies (diff is also coming soon), so there is no reason to keep Haskell libraries in tree.

[mat]

lang/ghc/bsd.cabal.mk

12 ↗

(On Diff #54063)

This feels reversed. This way, you are touching every port that is not getting deprecated. So when the libraries go away, you have to touch them again to remove this variable from being set.

You should instead set a DEPRECATED_LIB variable in the haskell library ports, and test for it here.

[arrowd]

We have 546 haskell ports, and only 37 of them aren't getting deprecated. You want me to add a variable to 509 ports instead of 37? What's the problem with adding and then removing a variable?

[tcberner]

In D19244#412377, @arrowd wrote:

We have 546 haskell ports, and only 37 of them aren't getting deprecated. You want me to add a variable to 509 ports instead of 37? What's the problem with adding and then removing a variable?

I agree with @arrowd here, that this way seems more sensible.

You have to inform @rene that these should not be auto-removed until the bsd.new-cabal.mk has landed.

[tcberner]

@mat can you live with it like this?

[rene]

That still leaves the question of *why* Haskell applications will be linked statically unanswered.

@crees , can you apply your patch to rmport so that it properly evaluates DEPRECATED and EXPIRATION_DATE instead of grepping them?

[arrowd]

In D19244#413471, @rene wrote:

That still leaves the question of *why* Haskell applications will be linked statically unanswered.

Haskell applications are linked statically even now. It is not about linkage, but dropping maintenance burden.

There were times when cabal install someapp could fail because it was always pulling latest dependencies, which might be not compatible with each other or the compiler. But now cabal became much smarter and we also have devel/stack, which uses curated set of Haskell packages. Our ports tree is also sort of curated package set and there is no point duplicating work.

Rust and Go ports also follow this route, so I think it is kind of established practice.

[antoine]

Please reverse the SKIP_DEPRECATION_NOTICE stuff, we mark deprecated ports, not non-deprecated ones.

[arrowd]

I'm not going to mark 500 ports as deprecated manually, nor I want to write/search for a script to do that. I'll just let them decay naturally, then.

[mat]

In D19244#414408, @arrowd wrote:

I'm not going to mark 500 ports as deprecated manually, nor I want to write/search for a script to do that. I'll just let them decay naturally, then.

Well, you have two portmgr members that asked you the same thing. Also, you will not let them decay. Please do as we ask.

[tcberner]

In D19244#414408, @arrowd wrote:

I'm not going to mark 500 ports as deprecated manually, nor I want to write/search for a script to do that. I'll just let them decay naturally, then.

I can write you a script.

[crees]

@rene, would you still like rmport patched? I can't remember why I reverted it.

[rene]

In D19244#414528, @crees wrote:

@rene, would you still like rmport patched? I can't remember why I reverted it.

Yes please. IIRC it was your patch was just never committed (the one that does "make -V EXPIRATION_DATE" instead of grepping it) . It would also help for Qt4, and for finding expired slave ports (which source their EXPIRATION_DATE from their master port, which is currently not visible for rmport).

I still have that patch around.

[crees]

At the risk of hijacking this conversation, I don't remember where I put my copy of the patch, but i remember it working correctly! Please go ahead and commit, it won't hurt :)

[arrowd]

In D19244#414496, @tcberner wrote:

In D19244#414408, @arrowd wrote:

I'm not going to mark 500 ports as deprecated manually, nor I want to write/search for a script to do that. I'll just let them decay naturally, then.

I can write you a script.

I will be eternally grateful if you commandeer this revision, of course.

In D19244#414458, @mat wrote:

In D19244#414408, @arrowd wrote:

I'm not going to mark 500 ports as deprecated manually, nor I want to write/search for a script to do that. I'll just let them decay naturally, then.

Well, you have two portmgr members that asked you the same thing.

You have the authority to decide what can be committed and what not, but you're not authority to me in a sense as employer is to his employee. If you want me to do that, you can give a rationale for such solution, at least.

Also, you will not let them decay.

I'm not native English speaker, so I might be wrong, but this sounds rude, like a dare. How do you make me not let them decay, if I just drop maintaining Haskell infrstructure? Sorry, if I interpreted this wrong.

[tcberner]

In D19244#414689, @arrowd wrote:

In D19244#414496, @tcberner wrote:

In D19244#414408, @arrowd wrote:

I'm not going to mark 500 ports as deprecated manually, nor I want to write/search for a script to do that. I'll just let them decay naturally, then.

I can write you a script.

I will be eternally grateful if you commandeer this revision, of course.

In D19244#414458, @mat wrote:

In D19244#414408, @arrowd wrote:

I'm not going to mark 500 ports as deprecated manually, nor I want to write/search for a script to do that. I'll just let them decay naturally, then.

Well, you have two portmgr members that asked you the same thing.

You have the authority to decide what can be committed and what not, but you're not authority to me in a sense as employer is to his employee. If you want me to do that, you can give a rationale for such solution, at least.

Also, you will not let them decay.

I'm not native English speaker, so I might be wrong, but this sounds rude, like a dare. How do you make me not let them decay, if I just drop maintaining Haskell infrstructure? Sorry, if I interpreted this wrong.

This is the one I used for Qt4 -- it does not do option handling, but thats not important as non of the ones to mark have have a optional hs-dependency (I think [tm]).
https://people.freebsd.org/~tcberner/scripts/mark_deprecated

The list of ports is basically just grep -rL SKIP_DEPRECATION */hs-*/Makefile | cut -d / -f 1,2 .

So

> mark_deprecated 2019-03-25 " Haskell libraries are getting pushed out of the ports tree. If you are using this port for development, consider switching to cabal sandboxes (old way), cabal new-build (new way), or use devel/stack. If you believe this port shouldn't be removed, contact [e-mail]"  `grep -rL SKIP_DEPRECATION */hs-*/Makefile | cut -d  / -f 1,2`

should theoretically get you there 99% of the way.

[tcberner]

Move DEPRECATED/EXPIRATION to the ports

[mat]

Thank you.

[tcberner]

@arrowd, what date do you think is realistic for the overhaul to take place?

[arrowd]

In D19244#419638, @tcberner wrote:

@arrowd, what date do you think is realistic for the overhaul to take place?

The only thing left is transforming .include <bsd.new-cabal.mk> to USES=cabal. I estimate that + review of the diff to ~ 2 weeks.

[arrowd]

It just came to my mind that we have 2 special ports - x11-wm/hs-xmonad and devel/hs-cabal-install itself. The new-cabal machinery can't be used for them right away, because in case of XMonad we have to install it as library, and in case of cabal-install we are in egg-and-chicken situation.

Our options:

1. We don't deprecate dependencies of x11-wm/hs-xmonad and devel/hs-cabal-install, so that old bsd.cabal.mk and some hs-* ports will stay.
2. I try to come up with something smart about these two ports, so that we don't have to special-case them.

Second option will require more work, so 2 weeks estimate is no longer valid.

[arrowd]

I took a look at cabal-install and it seem to have a bootstrap script that would allow building it without old bsd.cabal.mk stuff. So, I'll follow second way and try to hack hs-cabal-install and hs-xmonad ports to make them "standalone".