comment

1 files changed, 18 insertions, 0 deletions

diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds:_no_longer_usable_on_CentOS_6.5/comment_4_641389c7c52fa4f624ae74b5d32a6b1c._comment b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds:_no_longer_usable_on_CentOS_6.5/comment_4_641389c7c52fa4f624ae74b5d32a6b1c._comment
new file mode 100644
index 000000000..83a01311c
--- /dev/null
+++ b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds:_no_longer_usable_on_CentOS_6.5/comment_4_641389c7c52fa4f624ae74b5d32a6b1c._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-09-23T17:14:14Z"
+ content="""
+It might be possible to use stackage to get a build of all libraries from
+the base haskell platform that are not too far out of date and don't break
+too often. There is currently no way to upgrade such a build to get newer
+version of libraries except for throwing the whole build tree away and
+building all libraries again. So, it would be a lot of CPU on an ongoing basis,
+or a source of unfixed security bugs. 
+
+And, I think it would not be entirely non-fragile. It's not exactly unheard
+of for a new version of a haskell library to accidentially break
+compatability with the old version of ghc which is generally unused in the
+haskell community outside of debian stable. Or, to need a newer version of
+some C library headers than is in stable, or ...
+"""]]