Upgrading to monad-control-0.3
Hello, To package the latest and greatest version of git-annex I need to have monad-control-0.3. However this depend on the update of yesod and would break mongoDB as well. I'm quite short on times these days and would like to know if this is gonna happen soon or not? In the meantime I email the author of the mongoDB haskell package. All the best, -- Nicolas Pouillard http://nicolaspouillard.fr
On Mon, Jan 02, 2012 at 11:21:22AM +0100, Nicolas Pouillard wrote:
Hello,
To package the latest and greatest version of git-annex I need to have monad-control-0.3.
However this depend on the update of yesod and would break mongoDB as well.
I'm quite short on times these days and would like to know if this is gonna happen soon or not?
In the meantime I email the author of the mongoDB haskell package.
It's *very* unlikely to happen. As you probably noticed yourself any update to yesod would necessitate an update of attoparsec to at least 0.10, which in turn requires an update to text and text lives in [extra]. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay
On Mon, Jan 2, 2012 at 7:12 PM, Magnus Therning <magnus@therning.org> wrote:
On Mon, Jan 02, 2012 at 11:21:22AM +0100, Nicolas Pouillard wrote:
Hello,
To package the latest and greatest version of git-annex I need to have monad-control-0.3.
However this depend on the update of yesod and would break mongoDB as well.
I'm quite short on times these days and would like to know if this is gonna happen soon or not?
In the meantime I email the author of the mongoDB haskell package.
It's *very* unlikely to happen. As you probably noticed yourself any update to yesod would necessitate an update of attoparsec to at least 0.10, which in turn requires an update to text and text lives in [extra].
I didn't remember that this was so constrained. Did someone asked the maintainer? If there are good reasons to keep one of these packages at an old version then we should consider having multiple versions of such packages. I heartly persuaded that while we should keep that at a minimum we should have some packages at multiple versions. -- Nicolas Pouillard http://nicolaspouillard.fr
On Mon, Jan 02, 2012 at 08:11:31PM +0100, Nicolas Pouillard wrote:
On Mon, Jan 2, 2012 at 7:12 PM, Magnus Therning <magnus@therning.org> wrote:
On Mon, Jan 02, 2012 at 11:21:22AM +0100, Nicolas Pouillard wrote:
Hello,
To package the latest and greatest version of git-annex I need to have monad-control-0.3.
However this depend on the update of yesod and would break mongoDB as well.
I'm quite short on times these days and would like to know if this is gonna happen soon or not?
In the meantime I email the author of the mongoDB haskell package.
It's *very* unlikely to happen. As you probably noticed yourself any update to yesod would necessitate an update of attoparsec to at least 0.10, which in turn requires an update to text and text lives in [extra].
I didn't remember that this was so constrained. Did someone asked the maintainer? If there are good reasons to keep one of these packages at an old version then we should consider having multiple versions of such packages. I heartly persuaded that while we should keep that at a minimum we should have some packages at multiple versions.
This sort of situation is what is keeping a lot of [haskell] behind what's on hackage; the packages in [extra]/[community] (especially haskell-platform of course) tend to put some rather strict limits on what can be upgraded. I'm not convinced keeping multiple versions of packages is a good option though. I personally think that the better option would be to make sure we remove the obstacles currently in place that prevent us from tracking the edge of hackage. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
I'm hoping the version of text in [extra] can be upgraded - I just left a comment on xmobar-git [1] that it's been marked outdated since last month, and is behind Haskell Platform. It's blocking upgrade there, too. [1] https://aur.archlinux.org/packages.php?ID=44683 On Mon, Jan 2, 2012 at 10:12 AM, Magnus Therning <magnus@therning.org>wrote:
On Mon, Jan 02, 2012 at 11:21:22AM +0100, Nicolas Pouillard wrote:
Hello,
To package the latest and greatest version of git-annex I need to have monad-control-0.3.
However this depend on the update of yesod and would break mongoDB as well.
I'm quite short on times these days and would like to know if this is gonna happen soon or not?
In the meantime I email the author of the mongoDB haskell package.
It's *very* unlikely to happen. As you probably noticed yourself any update to yesod would necessitate an update of attoparsec to at least 0.10, which in turn requires an update to text and text lives in [extra].
/M
-- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay
_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
On Mon, Jan 02, 2012 at 07:38:59PM -0800, Leif Warner wrote:
I'm hoping the version of text in [extra] can be upgraded - I just left a comment on xmobar-git [1] that it's been marked outdated since last month, and is behind Haskell Platform. It's blocking upgrade there, too.
Slightly off-topic, the version of text in the latest haskell-platform still isn't the latest (0.11.1.5 vs. 0.11.1.12) so this situation is bound to come about again in the near future. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay
On Tue, Jan 3, 2012 at 7:11 AM, Magnus Therning <magnus@therning.org> wrote:
On Mon, Jan 02, 2012 at 07:38:59PM -0800, Leif Warner wrote:
I'm hoping the version of text in [extra] can be upgraded - I just left a comment on xmobar-git [1] that it's been marked outdated since last month, and is behind Haskell Platform. It's blocking upgrade there, too.
Slightly off-topic, the version of text in the latest haskell-platform still isn't the latest (0.11.1.5 vs. 0.11.1.12) so this situation is bound to come about again in the near future.
Indeed but I support the concept of the haskell-platform. It is too restrictive to only packages able to track the latest versions of their dependencies. I suggest we try this technique on one case first and the text package seems to be a good example. We could package the latest version of text and upgrade some package which depend on it. -- Nicolas Pouillard http://nicolaspouillard.fr
On Tue, Jan 3, 2012 at 10:12, Nicolas Pouillard <nicolas.pouillard@gmail.com> wrote:
On Tue, Jan 3, 2012 at 7:11 AM, Magnus Therning <magnus@therning.org> wrote:
On Mon, Jan 02, 2012 at 07:38:59PM -0800, Leif Warner wrote:
I'm hoping the version of text in [extra] can be upgraded - I just left a comment on xmobar-git [1] that it's been marked outdated since last month, and is behind Haskell Platform. It's blocking upgrade there, too.
Slightly off-topic, the version of text in the latest haskell-platform still isn't the latest (0.11.1.5 vs. 0.11.1.12) so this situation is bound to come about again in the near future.
Indeed but I support the concept of the haskell-platform. It is too restrictive to only packages able to track the latest versions of their dependencies.
I suggest we try this technique on one case first and the text package seems to be a good example. We could package the latest version of text and upgrade some package which depend on it.
I'm sorry, but what "technique" are you referring to here? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
On 01/03/2012 10:18 AM, Magnus Therning wrote:
On Tue, Jan 3, 2012 at 10:12, Nicolas Pouillard <nicolas.pouillard@gmail.com> wrote:
Indeed but I support the concept of the haskell-platform. It is too restrictive to only packages able to track the latest versions of their dependencies.
I suggest we try this technique on one case first and the text package seems to be a good example. We could package the latest version of text and upgrade some package which depend on it. I'm sorry, but what "technique" are you referring to here?
There was a proposal (in the far past) to add "-hp" to the name of all packages which belong to haskell platform (HP). The different name would allow to have a HP package version and one more package version which was supposed to be the very latest stable version. HP packages could depend only on other HP packages. Non-HP packages could depend on HP packages and also on non-HP packages. Not sure whether there is some fundamental problem why this cannot work or it was only forgotten. Looks to me like it could work. Peter.
On Tue, Jan 3, 2012 at 11:39 AM, Peter Hercek <phercek@gmail.com> wrote:
On 01/03/2012 10:18 AM, Magnus Therning wrote:
On Tue, Jan 3, 2012 at 10:12, Nicolas Pouillard <nicolas.pouillard@gmail.com> wrote:
Indeed but I support the concept of the haskell-platform. It is too
restrictive to only packages able to track the latest versions of their dependencies.
I suggest we try this technique on one case first and the text package seems to be a good example. We could package the latest version of text and upgrade some package which depend on it.
I'm sorry, but what "technique" are you referring to here?
Supporting multiple versions of a package by giving them different archlinux names.
There was a proposal (in the far past) to add "-hp" to the name of all packages which belong to haskell platform (HP). The different name would allow to have a HP package version and one more package version which was supposed to be the very latest stable version. HP packages could depend only on other HP packages. Non-HP packages could depend on HP packages and also on non-HP packages. Not sure whether there is some fundamental problem why this cannot work or it was only forgotten. Looks to me like it could work.
Indeed this is a solution. However it requires having control on all hp packages which we don't have. However either options are OK for me. -- Nicolas Pouillard http://nicolaspouillard.fr
On Tue, Jan 03, 2012 at 04:07:55PM +0100, Nicolas Pouillard wrote:
On Tue, Jan 3, 2012 at 11:39 AM, Peter Hercek <phercek@gmail.com> wrote:
On 01/03/2012 10:18 AM, Magnus Therning wrote:
On Tue, Jan 3, 2012 at 10:12, Nicolas Pouillard <nicolas.pouillard@gmail.com> wrote:
Indeed but I support the concept of the haskell-platform. It is too
restrictive to only packages able to track the latest versions of their dependencies.
I suggest we try this technique on one case first and the text package seems to be a good example. We could package the latest version of text and upgrade some package which depend on it.
I'm sorry, but what "technique" are you referring to here?
Supporting multiple versions of a package by giving them different archlinux names.
There is slightly more to it than just giving them different names, you'd also have to make sure they don't have any file paths in common. Also, if both packages provide docs then one should have precedence over the other. Also, a practical issue is that `cblrepo` isn't able to handle more than a single version of each package in its database.
There was a proposal (in the far past) to add "-hp" to the name of all packages which belong to haskell platform (HP). The different name would allow to have a HP package version and one more package version which was supposed to be the very latest stable version. HP packages could depend only on other HP packages. Non-HP packages could depend on HP packages and also on non-HP packages. Not sure whether there is some fundamental problem why this cannot work or it was only forgotten. Looks to me like it could work.
Indeed this is a solution. However it requires having control on all hp packages which we don't have. However either options are OK for me.
What would the purpose of providing two versions of some packages be? Just to tick the has-haskell-platform box, or is there more value to it? What packages should be built using the -hp packages? If any, should we try to do anything to avoid the diamond dependency problem? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
On Tue, Jan 3, 2012 at 6:32 PM, Magnus Therning <magnus@therning.org> wrote:
On Tue, Jan 03, 2012 at 04:07:55PM +0100, Nicolas Pouillard wrote:
On Tue, Jan 3, 2012 at 11:39 AM, Peter Hercek <phercek@gmail.com> wrote:
On 01/03/2012 10:18 AM, Magnus Therning wrote:
On Tue, Jan 3, 2012 at 10:12, Nicolas Pouillard <nicolas.pouillard@gmail.com> wrote:
Indeed but I support the concept of the haskell-platform. It is too
restrictive to only packages able to track the latest versions of their dependencies.
I suggest we try this technique on one case first and the text package seems to be a good example. We could package the latest version of text and upgrade some package which depend on it.
I'm sorry, but what "technique" are you referring to here?
Supporting multiple versions of a package by giving them different archlinux names.
There is slightly more to it than just giving them different names, you'd also have to make sure they don't have any file paths in common. Also, if both packages provide docs then one should have precedence over the other.
cabal supports installing multiple versions of the same packages so this should be pretty easy to do the same.
Also, a practical issue is that `cblrepo` isn't able to handle more than a single version of each package in its database.
Indeed.
There was a proposal (in the far past) to add "-hp" to the name of all packages which belong to haskell platform (HP). The different name would allow to have a HP package version and one more package version which was supposed to be the very latest stable version. HP packages could depend only on other HP packages. Non-HP packages could depend on HP packages and also on non-HP packages. Not sure whether there is some fundamental problem why this cannot work or it was only forgotten. Looks to me like it could work.
Indeed this is a solution. However it requires having control on all hp packages which we don't have. However either options are OK for me.
What would the purpose of providing two versions of some packages be? Just to tick the has-haskell-platform box, or is there more value to it? What packages should be built using the -hp packages? If any, should we try to do anything to avoid the diamond dependency problem?
The purpose is wider than this. Having a second version of a package (P, V1, V2), might enable to build a whole set of packages which requires P>V1 while another set requires P≤V1. Again, as long as we can push the authors to upgrade their packages this is fine but we cannot assume this will always be the case. -- Nicolas Pouillard http://nicolaspouillard.fr
On Tue, Jan 03, 2012 at 09:19:40PM +0100, Nicolas Pouillard wrote: [...]
cabal supports installing multiple versions of the same packages so this should be pretty easy to do the same.
Well, one of the things that cabal doesn't do is attempt to wire in the package docs into the system-wide index.html file. Not impossible to solve by any stretch of the imagination, but it just goes to show that it requires more thought and work than changing the name of a package in a PKGBUILD.
What would the purpose of providing two versions of some packages be? Just to tick the has-haskell-platform box, or is there more value to it? What packages should be built using the -hp packages? If any, should we try to do anything to avoid the diamond dependency problem?
The purpose is wider than this. Having a second version of a package (P, V1, V2), might enable to build a whole set of packages which requires P>V1 while another set requires P≤V1.
It would also risk causing diamond dependency problems among the packages in [haskell].
Again, as long as we can push the authors to upgrade their packages this is fine but we cannot assume this will always be the case.
True. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
On 01/03/2012 10:50 PM, Magnus Therning wrote:
On Tue, Jan 03, 2012 at 09:19:40PM +0100, Nicolas Pouillard wrote: [...]
cabal supports installing multiple versions of the same packages so this should be pretty easy to do the same. Well, one of the things that cabal doesn't do is attempt to wire in the package docs into the system-wide index.html file. Not impossible to solve by any stretch of the imagination, but it just goes to show that it requires more thought and work than changing the name of a package in a PKGBUILD.
What would the purpose of providing two versions of some packages be? Just to tick the has-haskell-platform box, or is there more value to it? What packages should be built using the -hp packages? If any, should we try to do anything to avoid the diamond dependency problem? The purpose is wider than this. Having a second version of a package (P, V1, V2), might enable to build a whole set of packages which requires P>V1 while another set requires P≤V1. It would also risk causing diamond dependency problems among the packages in [haskell]. Well, I would say this is a problem for people who not upgrade enough when their dependencies bring two different versions of the same package in.
It looks like people who want newer versions may rather maintain their own habs tree and probably forget anything haskell related from [extra]/[community]/[haskell]. At least, I plan to do so if I decide to move to ghc 7.4.1 sooner than archlinux community. I'm mostly behind, but I may get ahead of archlinux this one time. It would be a bit easier if we would have ghcDependency pacman group. Is there a way to ask pacman for all locally installed packages from a given source (i.e. one of [core]/[extra]/[community]/...)? E.g. a query like "get all locally installed packages which arrived from [extra] or [community] and contain string haskell in name or description".
Again, as long as we can push the authors to upgrade their packages this is fine but we cannot assume this will always be the case. True. Maintainers of haskell packages in [extra] and [community] do not seem to respond here. Google search indicates that there is not much haskell related discussion in arch-dev-public (I'm not a subscriber so I do not know for sure). Is there some other list where to get reaction from [extra]/[community] haskell maintainers?
Providing packages (which are old in [extra]/[community]) also in [haskell] repository would mitigate this problem a bit. Users just need to ensure they have [haskell] before [extra]/[community] in pacman.conf. Or just put everything in [haskell]. Peter.
participants (4)
-
Leif Warner -
Magnus Therning -
Nicolas Pouillard -
Peter Hercek