On Tue, Dec 4, 2012 at 10:21 PM, Magnus Therning <mag...@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). > > /M > > -- > Magnus Therning OpenPGP: 0xAB4DFBA4 > email: mag...@therning.org jabber: mag...@therning.org > twitter: magthe http://therning.org/magnus > > I invented the term Object-Oriented, and I can tell you I did not have > C++ in mind. > -- Alan Kay >
_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
