[Hackage] #462: Automatic rebuild of depending packages once failed dependency re-uploaded and builds.
#462: Automatic rebuild of depending packages once failed dependency re-uploaded and builds. --------------------------------+------------------------------------------- Reporter: golubovsky | Owner: Type: enhancement | Status: new Priority: normal | Milestone: HackageDB Component: hackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | --------------------------------+------------------------------------------- Given these packages: C depends on B, B depends on A. A failed to build, B and C were uploaded later and failed also. Later, A was fixed, bumped version, re-uploaded. B did not need fixing, so remained untouched. C was also fixed, bumped version, re-uploaded. Finally, A rebuilt OK, B was not scheduled for rebuilding, C failed because B was still failed. It is requested that once a package that failed to build is updated and builds, all packages immediately dependent upon it are scheduled for rebuild. Then the same logic applies to those that rebuilt OK (their dependencies are scheduled for rebuild). Thanks. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/462 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#462: Automatic rebuild of depending packages once failed dependency re-uploaded and builds. --------------------------------+------------------------------------------- Reporter: golubovsky | Owner: Type: enhancement | Status: new Priority: normal | Milestone: _|_ Component: hackageDB website | Version: Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.10.1 | Platform: --------------------------------+------------------------------------------- Changes (by duncan): * difficulty: normal => hard (< 1 day) * version: 1.2.3.0 => * milestone: HackageDB => _|_ Comment: This is all because the current builder does not do any kind of dependency tracking (like cabal-install does). Personally I think it's not worth fixing up and we should work on the new hackage-server and build reporting which does use cabal-install clients and so will not have this problem. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/462#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#462: Automatic rebuild of depending packages once failed dependency re-uploaded and builds. --------------------------------+------------------------------------------- Reporter: golubovsky | Owner: Type: enhancement | Status: new Priority: normal | Milestone: _|_ Component: hackageDB website | Version: Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.10.1 | Platform: --------------------------------+------------------------------------------- Comment (by duncan): See also http://www.haskell.org/pipermail/haskell- cafe/2009-January/053247.html (taken from #468). See #184 for the proper solution (ie not using the current builder). -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/462#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#462: Automatic rebuild of depending packages once failed dependency re-uploaded and builds. --------------------------------+------------------------------------------- Reporter: golubovsky | Owner: Type: enhancement | Status: new Priority: normal | Milestone: _|_ Component: hackageDB website | Version: Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.10.1 | Platform: --------------------------------+------------------------------------------- Changes (by duncan): * cc: cabal@henning-thielemann.de (added) -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/462#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#462: Automatic rebuild of depending packages once failed dependency re-uploaded and builds. --------------------------------+------------------------------------------- Reporter: golubovsky | Owner: Type: enhancement | Status: new Priority: normal | Milestone: _|_ Component: hackageDB website | Version: Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.10.1 | Platform: --------------------------------+------------------------------------------- Comment (by golubovsky): Or, instead of any re-building automation, is it possible to allow re- uploading of a package with the same version if it failed to build? Currently, per what the page http://hackage.haskell.org/packages/upload.html says, '''Re-uploading a package with the same version number is not permitted''' This could in part resolve the original issue: re-uploading of a package would trigger its rebuilding. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/462#comment:4 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#462: Automatic rebuild of depending packages once failed dependency re-uploaded and builds. --------------------------------+------------------------------------------- Reporter: golubovsky | Owner: Type: enhancement | Status: new Priority: normal | Milestone: _|_ Component: hackageDB website | Version: Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.10.1 | Platform: --------------------------------+------------------------------------------- Comment (by mokus): Re-uploading would not even be necessary in most cases. A "request rebuilding" or "vote to rebuild" option on every package would be very nice (probably require an account with upload permissions and log requests in case of abuse). Or, a new build-failure fallback mode where a failed build is retried using cabal install in a fresh package.conf environment to ensure that any failures are genuine and not the fault of the hackage server itself. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/462#comment:5 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#462: Automatic rebuild of depending packages once failed dependency re-uploaded and builds. --------------------------------+------------------------------------------- Reporter: golubovsky | Owner: Type: enhancement | Status: new Priority: normal | Milestone: _|_ Component: hackageDB website | Version: Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.10.1 | Platform: --------------------------------+------------------------------------------- Comment (by malcolm.wallace@cs.york.ac.uk): I'm not sure I understand why the Hackage server is building packages in the first place. Surely the only thing of interest is generating documentation - why is a full build necessary? -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/462#comment:6 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
I'm not sure I understand why the Hackage server is building packages in
#462: Automatic rebuild of depending packages once failed dependency re-uploaded and builds. --------------------------------+------------------------------------------- Reporter: golubovsky | Owner: Type: enhancement | Status: new Priority: normal | Milestone: _|_ Component: hackageDB website | Version: Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.10.1 | Platform: --------------------------------+------------------------------------------- Comment (by mokus): Replying to [comment:6 malcolm.wallace@cs.york.ac.uk]: the first place. Surely the only thing of interest is generating documentation - why is a full build necessary? That's a very good point too, and I suspect there are some cabal- architecture-related reasons for it - a full build is probably the easiest way to get the documentation to build, especially when you consider the way cabal builds can depend non-trivially on the set of installed packages or really anything else the Setup.hs file wants to check. I for one agree that I only really care whether my documentation gets built, though. I've been a bit annoyed lately because of things like the bytestring 0.9.1.5 update, not so much because of the build-failure black mark my project gets as a result but because it also keeps my documentation from building. As I mentioned a few minutes ago at the end of my comment at http://hackage.haskell.org/trac/hackage/ticket/598#comment:2, I believe that many users are put off a package much more by lack of easily- accessible documentation than by the fact that it didn't build on some particular machine. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/462#comment:7 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#462: Automatic rebuild of depending packages once failed dependency re-uploaded and builds. --------------------------------+------------------------------------------- Reporter: golubovsky | Owner: Type: enhancement | Status: new Priority: normal | Milestone: _|_ Component: hackageDB website | Version: Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.10.1 | Platform: --------------------------------+------------------------------------------- Comment (by malcolm.wallace@cs.york.ac.uk): So it seems to me that a purely-documentation build does not (or should not) need any of the depended-upon packages to be available, which would solve the immediate problem reported in this ticket. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/462#comment:8 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#462: Automatic rebuild of depending packages once failed dependency re-uploaded and builds. --------------------------------+------------------------------------------- Reporter: golubovsky | Owner: Type: enhancement | Status: new Priority: normal | Milestone: _|_ Component: hackageDB website | Version: Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.10.1 | Platform: --------------------------------+------------------------------------------- Comment (by guest): A purely documentation build does too need depended-on packages! At least if: it re-exports any functions or data types from another package (whether that package gives them documentation strings or not) it exports a type depending on a type-synonym in another package etc. Also I think the way Haddock 2 is designed, using the GHC API, even in "simpler" cases there is probably necessarily a requirement on the depended-upon packages (.hi files) to be available. -Isaac Dupree -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/462#comment:9 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#462: Automatic rebuild of depending packages once failed dependency re-uploaded and builds. --------------------------------+------------------------------------------- Reporter: golubovsky | Owner: Type: enhancement | Status: new Priority: normal | Milestone: _|_ Component: hackageDB website | Version: Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.10.1 | Platform: --------------------------------+------------------------------------------- Comment (by mokus): Replying to [comment:8 malcolm.wallace@cs.york.ac.uk]:
So it seems to me that a purely-documentation build does not (or should not) need any of the depended-upon packages to be available, which would solve the immediate problem reported in this ticket.
In theory it should not. In practice there is at least two cases that would require careful attention: 1) I believe haddock evaluates any template-haskell splices in the code it's processing (though I could be wrong on that). 2) Setup.hs may itself depend on some of the build-depends. I don't know whether this sort of thing actually happens, and it seems to me that it ought to be discouraged anyway because of the implicit chicken-and-egg problem. This case could probably be reasonably written off as something to "do at your own risk". Neither of those is insurmountable, obviously, but they do spring to my mind at least as potential challenges. Both cases could be handled by aggressive preconditioning by "cabal sdist", or perhaps it would still be reasonable to just do a full build in such cases and any other exceptional circumstances that may exist. I don't know how deep the difficulties Isaac Dupree mentions run, but even if they can be handled by clever caching of type and documentation information (which I suspect), the implementation of such a system would probably be far from trivial. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/462#comment:10 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#462: Automatic rebuild of depending packages once failed dependency re-uploaded and builds. --------------------------------+------------------------------------------- Reporter: golubovsky | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: _|_ Component: hackageDB website | Version: Severity: normal | Resolution: duplicate Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.10.1 | Platform: --------------------------------+------------------------------------------- Changes (by ross): * status: new => closed * resolution: => duplicate Comment: see #598 for the medium term and #184 for the long term. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/462#comment:12 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
participants (1)
-
Hackage