On Tue, Dec 4, 2012 at 10:21 PM, Magnus Therning
<magnus@therning.org> wrote:
> This are my suggestions:
>
> 1. Magnus keep a [haskell-base] repository. This MUST be an Arch repo
> in sync with a github repo.
> 2. Both repositories (Arch and git) should be available for
> maintainers of other repository.
> 3. Maintainer of [haskell-web] (me) MUST update it's repo to keep in
> sync with base in a reasonable time.
> 4. After this time a “global maintainer” (Magnus, Ramana, me, whoever)
> can grab all packages from both repositories and put them in a new
> one: [haskell]
> 5. Only [haskell] is intended for end users.
>
> A “reasonable time” could be 3 days. I saw that Magnus updates the
> repo on Wednesday and on Saturday/Sunday: so before the next update
> [haskell-web] should be in sync.
>
> I developed [haskell-web] in a way that it will not duplicate packages
> from [haskell]: I use them as DistroPkg. Updating is easy with
> `cbladmin` [^1], there's no need to modify `cblrepo`, maybe you could
> merge (and develop) some ideas from there. But this is not the main
> point. The main point is to be in sync, or else I'm just wasting my
> time, as [haskell-web] will never be really useful.
The big piece that's missing above is how to handle failures to
upgrade a package caused by a dependant not allowing the upgrade. Do
we hold off the base-test repo then?
I currently upgrade everything I can in one transaction, what if one
of the packages requires holding back due to a dependant. Would that
require a partial roll-back in the base-test repo?
I don't understand the issue here. The only requirement is that the [haskell-base] Arch repo and github repo are always in sync with each other.
I don't think a change to haskell-base necessarily needs to be only version updates, there might be rollbacks if they are necessary. But whatever changes are made to haskell-base, eventually haskell-web and other haskell- repos will be made to work with it (in a reasonable time), and then when a good state is reached, [haskell] itself can be updated. So it's always in a good state. It might mean waiting longer for updates to make their way from hackage to [haskell].
It's questions like these that I don't have a good answer to. And
yes, both situations have occurred in the past. They both cause a bit
of work (though not so much if they are caught already at 'clbrepo
updates' time).
I invented the term Object-Oriented, and I can tell you I did not have
C++ in mind.
-- Alan Kay