
Hi guys, the following commits updates a hand full of habs packages to the latest available versions: http://github.com/archhaskell/habs/commit/78b2f329c3b2e5692a40832da3fce2f6c5... These files have been generated with the latest tool-chain, which comes with several updates: * the original cabal name of every package is available as ${_hkgname}, * the generated uninstall.sh hook uses --force to avoid warnings during updates, * packages provided by GHC are no longer listed as dependencies, and * our attribution header of choice these days is "Maintainer:". I have tested the changes extensively, and everything seems to work fine. If there is no objection, I would like to upload these updated packages to AUR. Take care, Peter

On Sun, Oct 31, 2010 at 23:39, Peter Simons
Hi guys,
the following commits updates a hand full of habs packages to the latest available versions:
http://github.com/archhaskell/habs/commit/78b2f329c3b2e5692a40832da3fce2f6c5...
These files have been generated with the latest tool-chain, which comes with several updates:
* the original cabal name of every package is available as ${_hkgname},
Good improvement.
* the generated uninstall.sh hook uses --force to avoid warnings during updates,
I have my doubts about this change, simply because suppressing warning messages make me queazy :-) It's probably good for now though.
* packages provided by GHC are no longer listed as dependencies, and
I strongly disagree with this one, I'd rather see the dependency list continue to include the meta-packages provided by the ghc package.
* our attribution header of choice these days is "Maintainer:".
Good.
I have tested the changes extensively, and everything seems to work fine. If there is no objection, I would like to upload these updated packages to AUR.
/M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus@therning.org http://therning.org/magnus identi.ca|twitter: magthe

Hi Magnus,
* packages provided by GHC are no longer listed as dependencies
I strongly disagree with this one, I'd rather see the dependency list continue to include the meta-packages provided by the ghc package.
Remy has put time and effort into developing that feature, and it's been in Git for almost two weeks. Now, you disagree strongly. Could you please describe how you intend to resolve the current situation? Would you like Remy's patches revoked? And if that is the case, exactly which ones? What do you suggest we do? Take care, Peter

On Mon, Nov 1, 2010 at 14:28, Peter Simons
Hi Magnus,
>> * packages provided by GHC are no longer listed as dependencies > > I strongly disagree with this one, I'd rather see the dependency list > continue to include the meta-packages provided by the ghc package.
Remy has put time and effort into developing that feature, and it's been in Git for almost two weeks. Now, you disagree strongly. Could you please describe how you intend to resolve the current situation? Would you like Remy's patches revoked? And if that is the case, exactly which ones? What do you suggest we do?
Well, I didn't know he was doing that. Which is my fault, I haven't been reading through all the patches that has gone into cabal2arch/archlinux. So, this is how I understand the situation: In the past, when cabal2arch saw a dependency on 'base', then it would insert a dependency on 'haskell-base'. The 'ghc' package then states that it provides 'haskell-base', and pacman (and other package managers) could use this to resolve dependencies correctly. It was then the job of the 'ghc' package maintainer to correctly state all the packages that are provided. (I should also note this behaviour was added with commit d4107f03211c79e2dba4, http://github.com/archhaskell/cabal2arch/commit/d4107f03211c79e2dba4304ac9da...). The situation now is that 'cabal2arch' (or rather 'archlinux') again knows what packages are provided by the 'ghc' package. Resulting in a list that has to be maintained by a person who isn't intimately involved in packaging 'ghc' (like this commit: http://github.com/archhaskell/archlinux/commit/4ce5f0415ebc070640b29439b036e...). AFAICS this also forces a re-release of cabal2arch when the list of core packages changes. Now, I'm convinced that depending on the core packages through the pacman mechanism, and therefore relying on proper 'provides' in ghc, is the correct thing to do. Feel free to convince me otherwise. As to how we resolve this, well, this is why we have a versioning system. Practically, backing out Remy's changes is perfectly doable. However, before we discuss the practicalities I'd like to know why Remy felt it was desirable to revert to the old behaviour at all. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus@therning.org http://therning.org/magnus identi.ca|twitter: magthe

Hi Magnus,
The situation now is that 'cabal2arch' (or rather 'archlinux') again knows what packages are provided by the 'ghc' package. Resulting in a list that has to be maintained by a person who isn't intimately involved in packaging 'ghc' [...]. AFAICS this also forces a re-release of cabal2arch when the list of core packages changes.
you are right, this is a very convincing reason to list all dependencies, including those on standard libraries. I understand those changes were pushed to 'master' by accident; so I suggest we revert them. I am still in favor of dropping the comment about 'provides', though, because IMHO the issue yahourt had with that feature has been fixed; 'provides' should not cause any trouble for anyone anymore. Eventually, we might even consider replacing the dependency on "ghc" with, say "haskell-compiler", and have "ghc" provide that. This change would open the door for supporting other compilers transparently. Take care Peter

On 2010/11/1 Peter Simons
Hi Magnus,
>> * packages provided by GHC are no longer listed as dependencies > > I strongly disagree with this one, I'd rather see the dependency list > continue to include the meta-packages provided by the ghc package.
Remy has put time and effort into developing that feature, and it's been in Git for almost two weeks. Now, you disagree strongly. Could you please describe how you intend to resolve the current situation? Would you like Remy's patches revoked? And if that is the case, exactly which ones? What do you suggest we do?
Sorry, I never intended to do anything like this: I only wanted to put the list of dependencies which should be eliminated in a separate file. It only happened that I wanted (locally on my machine) to include base packages (like haskell-containers) into the list of dependencies that should be eliminated, and that change got commited to the main repository by accident some days ago, as I said in another mail. This change is still subject to discussion. -- Rémy.

On 01/11/10 17:22, Rémy Oudompheng wrote:
On 2010/11/1 Peter Simons
wrote: Hi Magnus,
* packages provided by GHC are no longer listed as dependencies
I strongly disagree with this one, I'd rather see the dependency list continue to include the meta-packages provided by the ghc package.
Remy has put time and effort into developing that feature, and it's been in Git for almost two weeks. Now, you disagree strongly. Could you please describe how you intend to resolve the current situation? Would you like Remy's patches revoked? And if that is the case, exactly which ones? What do you suggest we do?
Sorry, I never intended to do anything like this: I only wanted to put the list of dependencies which should be eliminated in a separate file. It only happened that I wanted (locally on my machine) to include base packages (like haskell-containers) into the list of dependencies that should be eliminated, and that change got commited to the main repository by accident some days ago, as I said in another mail.
This change is still subject to discussion.
No worries. I think we all have made the same type of mistake (and I sure have made some rather more serious ones). It seems to me that Peter is leaning towards the same opinion as me, so unless you still have strong opinions to keep this list in 'archlinux' would you mind reverting the code to once again generate the full list of dependencies (i.e. make use of ghc's extended list of provides)? You are very familiar with the code in 'archlinux' by now, so it'll probably be easiest for you to revert the change yourself. Is that all right with you, Remy? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus@therning.org http://therning.org/magnus identi.ca|twitter: magthe

On 2010/11/1 Magnus Therning
It seems to me that Peter is leaning towards the same opinion as me, so unless you still have strong opinions to keep this list in 'archlinux' would you mind reverting the code to once again generate the full list of dependencies (i.e. make use of ghc's extended list of provides)?
You are very familiar with the code in 'archlinux' by now, so it'll probably be easiest for you to revert the change yourself. Is that all right with you, Remy?
I commented the relevant part of "ghc-provides.txt", reverting it back to its former state. -- Rémy.

On Tue, Nov 2, 2010 at 07:42, Rémy Oudompheng
On 2010/11/1 Magnus Therning
wrote: It seems to me that Peter is leaning towards the same opinion as me, so unless you still have strong opinions to keep this list in 'archlinux' would you mind reverting the code to once again generate the full list of dependencies (i.e. make use of ghc's extended list of provides)?
You are very familiar with the code in 'archlinux' by now, so it'll probably be easiest for you to revert the change yourself. Is that all right with you, Remy?
I commented the relevant part of "ghc-provides.txt", reverting it back to its former state.
Cool! :-) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus@therning.org http://therning.org/magnus identi.ca|twitter: magthe
participants (3)
-
Magnus Therning
-
Peter Simons
-
Rémy Oudompheng