search

archhaskell / habs

Arch Haskell ABS tree
http://github.com/archhaskell/habs
80 stars 28 forks source link

Leveraging Stackage #192

Closed johannesgerer closed 8 years ago

johannesgerer commented 9 years ago

Stackage is nothing more than set of package versions

build consistently and pass tests -- https://www.stackage.org/

given in form of a Cabal config file with contraints: https://www.stackage.org/nightly/cabal.config.

So they are duplicating the part of your effort concerned with selecting a consistent set of packages. It also seems that they have more resources, meaning more in numbers, more up-to-date and maybe more reliable packages and for more versions of GHC than provided by habs. Furthermore, they provide an automatic way for authors to submit packages, that will benefit all Stackage users (i.e. all LInux, Mac and Windows not only Arch), and as such has a very high incentive for author to use it compared to ArchHaskell. So in total it is a very good idea to focus these efforts for the whole Haskell community.

Long story short, I think switching ArchHaskell to build all Stackage Packages is a win-win situation:

Are there any reasons not to do this?

magthe commented 9 years ago

Stackage is indeed a curated set of packages that is verified to build and function together. As such is isn't much different from ArchHaskell. That does make it interesting to base ArchHaskell on it. One way of doing this would be to

  1. munge the file with constraints and turn them into something that can be diffed against the cblrepo DB
  2. any differences can then be updated/added to the cblrepo DB
  3. these changes would then be handled in the normal way, bump all packages depending on modified packages, create PKGBUILDs, then build it all (in short, normal cblrepo usage)

There is really only one reason not to do this:

ghost commented 9 years ago

So this need to be examined from other perspectives too. Maybe we need to reduce the update frequency by (up to) a factor of 4. Cabal is the way for those who need bleeding edge code. The rest is a case of creating dependable distribution libraries for Arch, so that applications based on them can rely on OS provided libraries.

magthe commented 9 years ago

@orbifx I disagree, ArchLinux is all about packaging the latest releases of SW, so following Hackage and trying to keep up with it is very much the "Arch way" as I understand it.

ghost commented 9 years ago

Yes the latest versions, but they should be presumed production ready which bleeding edge isn't always presumed to be.

Also I believe the Arch way is that the collection of packages at a moment of time should be able to work together, something which seems to be a regular issue with Hackage and thus the creation of Stackage.

Basically what I am saying is: Stackage Nightly should still be cutting edge enough, but provide the set of packages which solves dependency issues arising from Hackage.

johannesgerer commented 9 years ago

Writing again, as the haskell-core again breaks my pacman -Syu. I think there are two separate issues. (1) Selecting the package versions and (2) building them. I think for the various reasons stated above, which enjoy consensus, (1) should use Stackage Nightly, which is should be as close to a bleeding edge and compatible subset of Hackage as possible. If these are too many to be handled by your current build system, the solution to (2) should be, to limit to a subset of Stackage. What do think about that?

LeifW commented 9 years ago

@orbifx What other metric for "production ready" would you want? The assumption is the maintainer wouldn't have released a new version of a package if it wasn't ready. "collection of packages at a moment of time should be able to work together" is provided by the [haskell-core] repo. Is there something about the current setup that isn't working for you, that stackage would address?

LeifW commented 9 years ago

@johannesgerer Building a subset of stackage sounds interesting. I personally don't care much one way or the other if the versions selected are the ones currently in ArchHaskell, or from Stackage nightly - as long as they are generally up-to-date. For people using stackage elsewhere, having at least a subset provided pre-built by [haskell-core] sounds like a nice benefit.

magthe commented 9 years ago

@johannesgerer Please tell me in what way haskell-core breaks your use of pacman -Syu.

ghost commented 9 years ago

I agree with @johannesgerer.

@LeifW Not every developer releases a new version with stability for the end user in mind, because sometimes they want to shoot first and ask questions later (no issue with that). It is also hard for a developer to anticipate the permutations of using the package in a system with other dependencies. The issue here is the observed fragility in the dependencies of the packages and the rate at which they break them. Seems to be high enough to annoy some but not too many.

Nevertheless I second the Stackage proposal because I think that users don't want daily or even weekly updates of over 100MiB. Haskell devs (including my self) should aim for long-term, minimalistic programs to reduce the resources (effort, cycles, memory, bandwidth) required to own Haskell applications.

magthe commented 9 years ago

@orbifx I'm not sure that using Stackage will somehow "fix" that upstream releases software that isn't actually release ready. AFAIK the Stackage set doesn't receive any extensive testing; to the best of my knowledge @snoyberg only verifies that the packages build together, which is exactly what we do.

I'm not sure what you mean by "fragility of dependencies". I don't personally experience anything that could be described that way. We did have a lot of that, which is why cblrepo was developed.

I don't think tying ourselves to the stable Stackage is a good idea. Using Stackage nightly could be a good idea, but AFAIU that won't mean the end of the large upgrades. Since a new version of a package requires re-building of all packages depending on it we're stuck with frequent large upgrades.

ghost commented 9 years ago

@magthe Why do you think tying to the stable Stackage isn't a good idea?

magthe commented 9 years ago

@orbifx For the simple reason that it's not what Arch Linux users expect... They expect the latest release of packages, unless there's a really good reason. That's basically why packaging Haskell Platform isn't a good idea either.

snoyberg commented 9 years ago

The only additional thing in place that stackage does is run all test suites, which may catch some regressions.

I don't know enough to recommend LTS vs Nightly, but I think Nightly will be the smallest delta.

ghost commented 9 years ago

@magthe I understand what you are saying, which is why I'm not adamant that we go down the Stackage way. There is one last merit that I can see, which is: if Stackage is more popular that Arch-Haskell then it would give a wider base for developers to build their applications against.

But I can see how Stackage and Arch-Haskell overlap and how some attributes of Stackage conflict with Arch's philosophy, in particular with the "latest release". From where I stand this isn't an issue either way. If we can provide the stability Stackage provides (or better) and we can have fresher packages... enough said. Devs can make their own choice what platform they target.

magthe commented 9 years ago

I'm still sort of liking the idea, but of rather different reasons (I still don't know what you mean when you refer to "fragility" and "stability issues"). I just have to think a little about how to deal with the packages we have in Arch Haskell that aren't in Stackage (maybe the easiest is to get involved in the Stackage effort myself... I'll think about it).

snoyberg commented 9 years ago

On that front: adding new packages to Stackage that build with the newest versions of their dependencies should be really simple. If you let me know which packages are missing, I can work through it with you.

ghost commented 9 years ago

By fragility, I mean how unreliable the system is, how often issues occur (in this case with deps). And I've used "stability" as opposite to fragility. Mostly with regards to dependencies.

magthe commented 9 years ago

That's exactly what I don't understand. I don't experience the system as fragile at all... what's the observable fragility you are referring to?

ghost commented 9 years ago

An instance for example when Pandoc wasn't available for a while because of issues. Maybe that was a one off and I've formed an opinion out of a singular case. The rest of my opinion is formed by how strict dependencies can be on packages (take pandoc again for example), which is not caused by Arch-Haskell but its tough work for distribution maintainers.

Another example is a package which I develop recently broke because some other package disappeared from Hackage. It might be coming from a C/C++/Linux background and comparing it with the fast developing Haskell, which makes the Haskell ecosystem seem a bit "fragile". But I love it and so I want to help make it a good platform.

You may ignore the above as anecdotal cases, but the cause of stable platform (enduring, less frequently changing APIs..), comparable to popular libraries for Linux is something that would eventually benefit Haskell.

LeifW commented 9 years ago

Some program maintainers want to build against a fixed set of package versions to increase the odds of the end-user getting a successful install, e.g. have the version numbers pinned in a cabal.config file. https://github.com/idris-lang/Idris-dev/issues/2135 I'll go through and compare the versions in stackage nightly with what's in habs. Many so far seem at identical versions; however stackage is at syb 0.4.4, while we're at 0.5.1. I wonder if there's a reason for this, or maybe we can just get the one in stackage bumped up.

LeifW commented 9 years ago

There's 886 packages in stackage not in habs, and the 50 in habs not in stackage are:

SafeSemaphore
Unixutils-shadow
X11-xft
alsa-core
alsa-mixer
array
base
bin-package-db
binary
bktrees
bloomfilter
bytestring
cblrepo
containers
date-cache
dbus
deepseq
directory
dyre
filepath
ghc
ghc-prim
git-annex
gtk-traymanager
hasktags
hoopl
hpc
integer-gmp
interlude
io-storage
libxml-sax
maccatcher
pandoc-crossref
pretty
process
publicsuffixlist
pxsl-tools
rts
scan
system-argv0
taffybar
template-haskell
text-stream-decode
time
transformers
unix
xdg-basedir
xmonad
xmonad-contrib

For the 305 packages that they have in common, the versions specified coincide but for 15. Of those 15, stackage-nightly had a more recent version on 5 of them:

package stackage version habs version
Cabal 1.22.4.0 1.22.2.0
http-client 0.4.15 0.4.14
http-conduit 2.1.5.1 2.1.5
network-info 0.2.0.7 0.2.0.6
pandoc 1.14.1 1.14.0.4

And habs has more recent versions on the other ten:

package stackage version habs version
aeson 0.8.0.2 0.9.0.1
attoparsec 0.12.1.6 0.13.0.0
base-orphans 0.3.3 0.4.0
bifunctors 4.2.1 5
clock 0.4.6.0 0.5.1
free 4.11 4.12.1
gtk 0.13.7 0.13.8.1
profunctors 4.4.1 5.1.1
semigroupoids 4.3 5.0.0.2
syb 0.4.4 0.5.1
LeifW commented 9 years ago

Roughly the code use to do the above (leverages PkgDb from cblrepo): https://gist.github.com/LeifW/632e119d09ea0ee574f5

snoyberg commented 9 years ago

A number of the packages you listed as not being in stackage are core packages, which ship with GHC. They are included in stackage, but are stored in a different part of the yaml file.

On Mon, Jul 6, 2015, 12:14 AM Leif Warner notifications@github.com wrote:

Roughly the code use to do the above (leverages PkgDb from cblrepo): https://gist.github.com/LeifW/632e119d09ea0ee574f5

— Reply to this email directly or view it on GitHub https://github.com/archhaskell/habs/issues/192#issuecomment-118751017.

LeifW commented 9 years ago

Ah, which yaml file - this one? https://github.com/fpco/stackage/blob/master/build-constraints.yaml I don't see version constraints in there. I had just used this file for comparison: https://www.stackage.org/nightly-2015-07-06/cabal.config?download=true Now I see: I filtered out the ones without version constraints (the ones that just say "installed" in there), so the things that ship with GHC were not counted in there. So the actual list of packages in habs not in stackage is 30 long, and looks like this:

Crypto
SafeSemaphore
Unixutils-shadow
X11-xft
alsa-core
alsa-mixer
bktrees
bloomfilter
cblrepo
date-cache
dbus
dyre
git-annex
gtk-traymanager
hasktags
interlude
io-storage
libxml-sax
maccatcher
pandoc-crossref
publicsuffixlist
pxsl-tools
rts
scan
system-argv0
taffybar
text-stream-decode
xdg-basedir
xmonad
xmonad-contrib

rts isn't a hackage package, so that shouldn't be in the list, either. Not clear what it's doing in habs.

LeifW commented 9 years ago

Ah, found https://github.com/fpco/stackage-nightly/blob/master/nightly-2015-07-06.yaml Anyway, there's been some updates in stackage, so now there's 896 stackage packages not in habs, and the version diffs where they do coincide are: stackage more recent:

package stackage version habs version
Cabal 1.22.4.0 1.22.2.0
auto-update 0.1.2.2 0.1.2.1
hspec 2.1.8 2.1.7
hspec-core 2.1.8 2.1.7
hspec-discover 2.1.8 2.1.7
hspec-expectations 0.7.0 0.6.1.1
http-client 0.4.15 0.4.14
http-conduit 2.1.5.1 2.1.5
network-info 0.2.0.7 0.2.0.6
pandoc 1.14.1 1.14.0.4
stack 0.1.2.0 0.1.1.0
texmath 0.8.2.2 0.8.2
wai 3.0.3.0 3.0.2.3
wai-extra 3.0.8.0 3.0.7.1

habs more recent:

package stackage version habs version
aeson 0.8.0.2 0.9.0.1
attoparsec 0.12.1.6 0.13.0.0
base-orphans 0.3.3 0.4.0
bifunctors 4.2.1 5
free 4.11 4.12.1
gtk 0.13.7 0.13.8.1
profunctors 4.4.1 5.1.1
semigroupoids 4.3 5.0.0.2
magthe commented 9 years ago

@orbifx All examples you bring up were due to the release of 7.10.1. I opted to move [haskell-core] quickly to ghc 7.10 by removing all unbuildable packages, rather than wait for upstream to release new versions. When upgrading to 7.8 I had instead chosen to introduce a [haskell-testing] repo, that included all buildable packages. When the testing repo included all packages I renamed it to [haskell-core]. During that time though I basically made no upgrades to [haskell-core] due to the burden of maintaining two repos in parallel.

That was clearly a bad decision (I struggled during the absence of pandoc as well :) ). The next upgrade, to 7.12, I won't just remove packages like that.

magthe commented 9 years ago

@LeifW rts is in the HABS repo due to this:

% ghc-pkg list|grep rts
    rts-1.0

That is, I've simply added all packages that are listed by ghc-pkg list after installing ghc.

magthe commented 9 years ago

I've just pushed a development branch for cblrepo that supports configuring where the index file is fetched: https://github.com/magthe/cblrepo/tree/devo/cfg-file

This ought to make it easier if anyone feels like playing a bit with packaging (parts of) Stackage :)

magthe commented 9 years ago

@orbifx One addendum to my earlier comment about packages disappearing due to the upgrade to 7.10. Had I not removed packages then ArchHaskell would still be on 7.8 since ghc-mod still doesn't have a release that builds with 7.10.

So at some point it very well might become necessary to drop packages because upstream takes too long to release versions supporting the latest ghc.

ghost commented 9 years ago

@magthe and this is what I mean by dependency issues. You did well for following the Arch goal of latest packages, but Haskell's ecosystem is not making it easy. Thus why we are here discussing holding back on the latest and greatest. It is a tough call. Maybe we can "wait it out" and the packages will get better at backward compatibility.

As of late I've not had to write and compile anything serious to stress test the dependencies, so I don't know what the latest situation with 7.10 is. Won't be long till I'm back at it.

johannesgerer commented 8 years ago

@magthe:

@johannesgerer Please tell me in what way haskell-core breaks your use of pacman -Syu.

Running sudo pacmatic -Syyu --noconfirm today gives the following errors. I currently do not no the root of the problem, but this kind of error never occurs in core/community/extra. 

Recent ML chatter:
:: Synchronizing package databases...
 core                                          119.9 KiB   952K/s 00:00 [########################################] 100%
 haskell-core                                   82.8 KiB   209K/s 00:00 [########################################] 100%
 haskell-core.sig                               96.0   B  0.00B/s 00:00 [########################################] 100%
 extra                                        1759.9 KiB  2.88M/s 00:01 [########################################] 100%
 community                                       3.6 MiB  4.33M/s 00:01 [########################################] 100%
 multilib                                      173.1 KiB  4.57M/s 00:00 [########################################] 100%
:: Starting full system upgrade...
warning: firefox: ignoring package upgrade (47.0.1-2 => 48.0.1-1)
warning: grml-zsh-config: ignoring package upgrade (0.12.1-1 => 0.12.6-1)
:: Replace gtk2hs-buildtools with community/haskell-gtk2hs-buildtools? [Y/n]
warning: haskell-cassava: local (0.4.5.0_0-9) is newer than community (0.4.5.0-11)
warning: haskell-charset: local (0.3.7.1_0-9) is newer than community (0.3.7.1-11)
warning: haskell-cipher-aes: local (0.2.11_0-11) is newer than community (0.2.11-3)
warning: haskell-crypto-cipher-types: local (0.0.9_0-88) is newer than community (0.0.9-3)
warning: haskell-crypto-pubkey-types: local (0.4.3_0-88) is newer than community (0.4.3-1)
warning: haskell-deepseq-generics: local (0.2.0.0_0-3) is newer than community (0.2.0.0-1)
warning: haskell-hex: local (0.1.2_0-6) is newer than community (0.1.2-2)
warning: haskell-html: local (1.0.1.2_0-81) is newer than community (1.0.1.2-3)
warning: haskell-network-info: local (0.2.0.8_0-4) is newer than community (0.2.0.8-3)
warning: haskell-regex-pcre: local (0.94.4_0-83) is newer than community (0.94.4-2)
warning: haskell-securemem: local (0.1.9_0-11) is newer than community (0.1.9-3)
warning: haskell-uuid: local (1.3.12_0-1) is newer than community (1.3.12-7)
warning: haskell-uuid-types: local (1.0.3_0-1) is newer than community (1.0.3-2)
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: haskell-cassava: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-cassava: installing haskell-attoparsec (0.13.0.2_0-250) breaks dependency 'haskell-attoparsec=0.13.0.2_0-1'
:: haskell-cassava: installing haskell-blaze-builder (0.4.0.2_0-250) breaks dependency 'haskell-blaze-builder=0.4.0.2_0-1'
:: haskell-cassava: installing haskell-hashable (1.2.4.0_0-250) breaks dependency 'haskell-hashable=1.2.4.0_0-4'
:: haskell-cassava: installing haskell-text (1.2.2.1_0-250) breaks dependency 'haskell-text=1.2.2.1_0-1'
:: haskell-cassava: installing haskell-unordered-containers (0.2.7.1_0-250) breaks dependency 'haskell-unordered-containers=0.2.7.0_0-3'
:: haskell-cassava: installing haskell-vector (0.11.0.0_1-250) breaks dependency 'haskell-vector=0.11.0.0_1-3'
:: haskell-charset: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-charset: installing haskell-semigroups (0.18.2_0-250) breaks dependency 'haskell-semigroups=0.18.1_1-1'
:: haskell-charset: installing haskell-unordered-containers (0.2.7.1_0-250) breaks dependency 'haskell-unordered-containers=0.2.7.0_0-3'
:: haskell-cipher-aes: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-cipher-aes: installing haskell-byteable (0.1.1_0-250) breaks dependency 'haskell-byteable=0.1.1_0-81'
:: haskell-cipher-des: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-cipher-des: installing haskell-byteable (0.1.1_0-250) breaks dependency 'haskell-byteable=0.1.1_0-81'
:: haskell-cipher-rc4: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-cipher-rc4: installing haskell-byteable (0.1.1_0-250) breaks dependency 'haskell-byteable=0.1.1_0-81'
:: haskell-crypto-cipher-types: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-crypto-cipher-types: installing haskell-byteable (0.1.1_0-250) breaks dependency 'haskell-byteable=0.1.1_0-81'
:: haskell-crypto-pubkey-types: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-crypto-pubkey-types: installing haskell-asn1-encoding (0.9.4_0-250) breaks dependency 'haskell-asn1-encoding=0.9.3_0-9'
:: haskell-crypto-pubkey-types: installing haskell-asn1-types (0.3.2_0-250) breaks dependency 'haskell-asn1-types=0.3.2_0-7'
:: haskell-csv: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-csv: installing haskell-parsec (3.1.11_0-250) breaks dependency 'haskell-parsec=3.1.9_0-90'
:: haskell-deepseq-generics: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-fail: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-hex: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-html: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-hxt: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-hxt: installing haskell-hunit (1.3.1.1_0-250) breaks dependency 'haskell-hunit=1.3.1.1_0-3'
:: haskell-hxt: installing haskell-mtl (2.2.1_1-250) breaks dependency 'haskell-mtl=2.2.1_1-4'
:: haskell-hxt: installing haskell-network-uri (2.6.1.0_0-250) breaks dependency 'haskell-network-uri=2.6.1.0_0-1'
:: haskell-hxt: installing haskell-parsec (3.1.11_0-250) breaks dependency 'haskell-parsec=3.1.9_0-90'
:: haskell-hxt-charproperties: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-hxt-regex-xmlschema: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-hxt-regex-xmlschema: installing haskell-parsec (3.1.11_0-250) breaks dependency 'haskell-parsec=3.1.9_0-90'
:: haskell-hxt-regex-xmlschema: installing haskell-text (1.2.2.1_0-250) breaks dependency 'haskell-text=1.2.2.1_0-1'
:: haskell-hxt-unicode: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-network-info: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-raw-strings-qq: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-regex-pcre: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-regex-pcre: installing haskell-regex-base (0.93.2_0-250) breaks dependency 'haskell-regex-base=0.93.2_0-83'
:: haskell-securemem: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-securemem: installing haskell-byteable (0.1.1_0-250) breaks dependency 'haskell-byteable=0.1.1_0-81'
:: haskell-securemem: installing haskell-memory (0.13_0-250) breaks dependency 'haskell-memory=0.12_0-1'
:: haskell-th-expand-syns: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-th-expand-syns: installing haskell-syb (0.6_0-250) breaks dependency 'haskell-syb=0.6_0-4'
:: haskell-th-lift: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-th-lift-instances: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-th-lift-instances: installing haskell-text (1.2.2.1_0-250) breaks dependency 'haskell-text=1.2.2.1_0-1'
:: haskell-th-lift-instances: installing haskell-vector (0.11.0.0_1-250) breaks dependency 'haskell-vector=0.11.0.0_1-3'
:: haskell-th-orphans: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-th-orphans: installing haskell-mtl (2.2.1_1-250) breaks dependency 'haskell-mtl=2.2.1_1-4'
:: haskell-th-reify-many: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-th-reify-many: installing haskell-mtl (2.2.1_1-250) breaks dependency 'haskell-mtl=2.2.1_1-4'
:: haskell-th-reify-many: installing haskell-safe (0.3.9_0-250) breaks dependency 'haskell-safe=0.3.9_0-6'
:: haskell-uuid: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-uuid: installing haskell-cryptonite (0.17_0-250) breaks dependency 'haskell-cryptonite=0.15_0-1'
:: haskell-uuid: installing haskell-memory (0.13_0-250) breaks dependency 'haskell-memory=0.12_0-1'
:: haskell-uuid: installing haskell-random (1.1_0-250) breaks dependency 'haskell-random=1.1_0-91'
:: haskell-uuid: installing haskell-text (1.2.2.1_0-250) breaks dependency 'haskell-text=1.2.2.1_0-1'
:: haskell-uuid-types: installing ghc (8.0.1-1) breaks dependency 'ghc=7.10.3-3'
:: haskell-uuid-types: installing haskell-hashable (1.2.4.0_0-250) breaks dependency 'haskell-hashable=1.2.4.0_0-4'
:: haskell-uuid-types: installing haskell-random (1.1_0-250) breaks dependency 'haskell-random=1.1_0-91'
:: haskell-uuid-types: installing haskell-text (1.2.2.1_0-250) breaks dependency 'haskell-text=1.2.2.1_0-1'
No pacnew files to update.
magthe commented 8 years ago

@johannesgerer

Running sudo pacmatic -Syyu --noconfirm today gives the following errors. I currently do not no the root of the problem, but this kind of error never occurs in core/community/extra.

The root of the problem is simple. Yesterday I moved all packages from haskell-testing over to haskell-core, and since I have only built about 275 of the packages there will be some breakage. There were about 100 packages that didn't make it across this time.

johannesgerer commented 8 years ago

So with regard to the issue discussed here, the current pacman -Syu errors would not be fixed by moving to Slackage, but are due to limited resources available to the build process?

Does "breakage" imply, that I have to interfere manually? (Still not working)

magthe commented 8 years ago

@johannesgerer Yes, it's due to limited resources. Yes, you'll have to interfere manually.

johannesgerer commented 8 years ago

If you find the time, it would be great to really understand what went wrong and why building the other packages now would not solve the problem, that pacman -Syu does not work.

And also, what manual steps I have to take, to fix this on my side...

I think the problem indicated here

warning: haskell-uuid: local (1.3.12_0-1) is newer than community (1.3.12-8)

is, that pacman thinks my local uuid packge is newer than the community version. This does not seem to be intenden behavior (either on pacman's side or the version string with the _?).

magthe commented 8 years ago

@johannesgerer I'm not sure I understand the question but I wouldn't mind taking a shot at answering as best I can. However, this isn't really related to this particular ticket ("Leveraging Stackage"), would you mind moving the discussion to another ticket, or the mailing list?

magthe commented 8 years ago

I'm closing this issue now as it's become rather unfocused by now, and the original topic (if Stackage can be leveraged for the curating of packages) has not been the actual topic for a while.