LogoopenSUSE Build Service > Projects > openSUSE:Maintenance:5585 > Overview
Sign Up | Log In


No description set

Comments for openSUSE:Maintenance:5585 (11)

Andreas Stieger AndreasStieger wrote about 2 months ago

@mimi_vx we seem to have issues with how ghc-rpm-macros generates dependencies. Can you explain how the hash in the deps is generated? It does not play well with how obs regards packages as changed.

Ondřej Súkup mimi_vx wrote about 2 months ago

@AndreasStieger requires and provides are generated with ghc-pkg field package id|depends

sha is generated generated by GHC compiller in buildtime ...

looks like inconsistency caused by rebuild of GHC in middle of rebuilding repository , unfortunately GHC hans't deterministic build's and stable abi :(

Please trigger rebuild of GHC itself -- and then rebuild whole repo:(

Andreas Stieger AndreasStieger wrote about 1 month ago

@mimi_vx If ghc is not maintainable in a stable distribution, and the abi is unstable between builds, we may not be able to have it in the distribution at all? @adrianSuSE mentioned that this creates build loops in 42.2

Adrian Schröter adrianSuSE wrote about 1 month ago

This is not creating build loops, but it conflicts the way how we handle build cycles, so these packages will always become broken and would need manually re-triggring.

However, the important part would be from my POV that we will not be able to release a maintenance update later of some of the ghc packages if the builds are not reproducable. IMHO this is not acceptable for a stable distro, but it is up to @lnussel and @DimStar to decide about this.

Ludwig Nussel lnussel wrote about 1 month ago

I agree that this is quite bad behavior. Is there any way to avoid this hash?

Andreas Stieger AndreasStieger wrote about 1 month ago

The incident is locked, SR#427804.

I think the problem is that the compiler breaks it's own ABI when rebuilt.

Ondřej Súkup mimi_vx wrote about 1 month ago

of course, due high optimization level in GHC isnt build fully deterministic. It's slowly changing .. but is run for long time. For openSUSE:Tumbleweed this isn't problem due constant rebuilds of Distribution. For stable release it need some care. And update whole dependency tree. ..

Ondřej Súkup mimi_vx wrote about 1 month ago

On SLE12SP1 x86_64 works good. I have now on my WKS installed whole update.

Now I try s390x

Peter Simons psimons wrote about 1 month ago

Haskell library packages have a unique identifier -- a hash that's computed over all functions and data types the library contains. When a library is linked into another library (or an application), the linker records that hash as part of the dependency information. This information guarantees that the library provided for the build cannot be changed at a later point; if you want to upgrade any component of the dependency tree, then you have to re-link all (transitive) dependents. Now, this is a fine mechanism to guarantee reliable builds for a language that relies heavily on cross-module in-lining, but unfortunately the hashes generated by the compiler are unstable (https://ghc.haskell.org/trac/ghc/ticket/4012). This means that two builds of the same source code may end up being assigned two different IDs. Consequently, there is no stable binary interface in GHC-compiled code. If any Haskell package is rebuilt, then all its (transitive) dependents must be re-built, too. An attempt to run an application that had any one of its dependencies re-compiled will fail with some non-zero probability (https://github.com/peti/ghc-library-id-bug). Since GHC provides some base libraries itself, a re-build of GHC must trigger a complete re-build of all Haskell packages to ensure that none of those packages get into a broken state.

The hashes you see in the dependency information visualize that information. I'm not sure how that works, exactly, but I believe the intention of that addition was to avoid unnecessary re-builds, i.e. if a re-compiled GHC does not change any of its library IDs, then all dependencies still match and no re-build are necessary. If any of the IDs do change, however, then RPM is able to detect that a given package is broken. Whether that triggers re-builds in OBS or not I'm not sure; but it seemed to me like those IDs did fix the missing re-builds for us when they were added into the dependency information.

Andreas Stieger AndreasStieger wrote about 1 month ago

Thanks, filed boo#998972 for tracking.