<div dir="ltr"><div><div><div><div><div>I agree that the up-to-date approach is the way to go: it fits well with Arch.<br></div>I suggest we continue that way.<br><br></div>Three items on the roadmap, then:<br><ol><li>Document the jobs of the maintainers of the merged repo, and of the satellite repos.<br>

</li><li>Set up the merged repo (and rename current [haskell] to [haskell-core] (or -base))</li><li>Document how to create new repos like [haskell-web].</li></ol></div>Fabio wrote something for 1 in a previous email; I will add it to the wiki and extend if I can.<br>

<br></div>Magnus, can you proceed with 2? If necessary I may be able to provide another server.<br><br></div>Fabio, can you start on 3 on the wiki, since you have the experience with haskell-web already?<br></div><div class="gmail_extra">

<br><br><div class="gmail_quote">On Mon, Dec 17, 2012 at 12:04 AM, Fabio Riga <span dir="ltr">&lt;<a href="mailto:rifabio@gmail.com" target="_blank">rifabio@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">2012/12/4 Magnus Therning &lt;<a href="mailto:magnus@therning.org">magnus@therning.org</a>&gt;<br>
&gt;<br>
&gt; Yeah, that&#39;s my bad.  I sometimes start updates and builds in the<br>
&gt; morning and then check in on them during the day.  If they succeed I<br>
&gt; push the new packages to the repo, but I only have write access to the<br>
&gt; github repos from my home computer.  I always plan to push the changes<br>
&gt; as soon as I get home, but you know what they say about the best laid<br>
&gt; schemes of mice and men; I sometimes forget and it might go days<br>
&gt; before I remember.<br>
<br>
</div>Sometimes it happens to me too, but no other repo is depending on<br>
mine, so nobody happens to know this!<br>
<div><div class="h5"><br>
&gt; &gt; This are my suggestions:<br>
&gt; &gt;<br>
&gt; &gt; 1. Magnus keep a [haskell-base] repository. This MUST be an Arch repo<br>
&gt; &gt; in sync with a github repo.<br>
&gt; &gt; 2. Both repositories (Arch and git) should be available for<br>
&gt; &gt; maintainers of other repository.<br>
&gt; &gt; 3. Maintainer of [haskell-web] (me) MUST update it&#39;s repo to keep in<br>
&gt; &gt; sync with base in a reasonable time.<br>
&gt; &gt; 4. After this time a “global maintainer” (Magnus, Ramana, me, whoever)<br>
&gt; &gt; can grab all packages from both repositories and put them in a new<br>
&gt; &gt; one: [haskell]<br>
&gt; &gt; 5. Only [haskell] is intended for end users.<br>
&gt; &gt;<br>
&gt; &gt; A “reasonable time” could be 3 days. I saw that Magnus updates the<br>
&gt; &gt; repo on Wednesday and on Saturday/Sunday: so before the next update<br>
&gt; &gt; [haskell-web] should be in sync.<br>
&gt; &gt;<br>
&gt; &gt; I developed [haskell-web] in a way that it will not duplicate packages<br>
&gt; &gt; from [haskell]: I use them as DistroPkg. Updating is easy with<br>
&gt; &gt; `cbladmin` [^1], there&#39;s no need to modify `cblrepo`, maybe you could<br>
&gt; &gt; merge (and develop) some ideas from there. But this is not the main<br>
&gt; &gt; point. The main point is to be in sync, or else I&#39;m just wasting my<br>
&gt; &gt; time, as [haskell-web] will never be really useful.<br>
&gt;<br>
&gt; The big piece that&#39;s missing above is how to handle failures to<br>
&gt; upgrade a package caused by a dependant not allowing the upgrade.  Do<br>
&gt; we hold off the base-test repo then?<br>
&gt; I currently upgrade everything I can in one transaction, what if one<br>
&gt; of the packages requires holding back due to a dependant.  Would that<br>
&gt; require a partial roll-back in the base-test repo?<br>
&gt;<br>
&gt; It&#39;s questions like these that I don&#39;t have a good answer to.  And<br>
&gt; yes, both situations have occurred in the past.  They both cause a bit<br>
&gt; of work (though not so much if they are caught already at &#39;clbrepo<br>
&gt; updates&#39; time).<br>
<br>
</div></div>I think here you are right, we don&#39;t have a real solution to this. In<br>
these days there are some discussions going in the haskell-cafè<br>
mailing list about the mess with cabal. The problem is not cabal,<br>
cblrepo or our different approaches to packaging for Arch. The problem<br>
is hackage.<br>
<br>
Every developer use different version of dependencies: someone is fast<br>
in keeping up-to-date, someone is more conservative, someone simply<br>
hasn&#39;t enough time to dedicate to his project and some projects are<br>
abandoned. We have to decide how many packages we want to include in<br>
[haskell] repo, and this depends on the approach we take: the<br>
up-to-date or the conservative.<br>
<br>
I call conservative what seems to have most consensus in haskell<br>
community: haskell-platform. There are A LOT of packages that simply<br>
don&#39;t work with ghc-7.6, because it&#39;s bleeding edge (the assumption<br>
is: if it is newer than HP, it&#39;s bleeding edge). This also was Arch<br>
approach until the switch from ghc-7.04 to 7.4.1. I feel that  if we<br>
use HP, our repository can be much more bigger and Arch haskellers can<br>
compile the most of hackage, if not packaged in archhaskell. The BIG<br>
drawback is that we&#39;ll have to avoid updating for the most active<br>
packages, and we will easily end up with the dependency nightmare.<br>
<br>
The up-to-date approach is what both of us are doing. I feel is more<br>
like in the Arch way and, IMHO, the right thing to do. There will be<br>
less packages in [haskell], but they are the most active ones. When a<br>
change in a dependency break a dependant, we usually should wait only<br>
few days. If the broken package persist, we will decide if taking it<br>
out from the repo or to switch to the conservative approach. Yes, this<br>
will happen and could require a partial roll-back, but I think it will<br>
be less frequent and easier to solve than trying to keep HP with less<br>
up-to-date packages.<br>
<br>
There are two other solutions: a more static approach and<br>
nix/cabal-dev/something similar.<br>
<br>
The static way could be: take Haskell Platform and build a repo with<br>
as much packages as possible, the most updated version that work, then<br>
stop. The next HP release (or every 6 months) repeat again. Isn&#39;t it<br>
the Ubuntu way? Maybe it&#39;s easier, but I don&#39;t like it.<br>
<br>
If somebody is for the cabal-dev approach, he surely would find the<br>
archhaskell effort useless. Still I don&#39;t see the point in cabal-dev,<br>
as projects are compiled statically. But this is off-topic here.<br>
<br>
Sorry for my verbosity, and this isn&#39;t a real answer to the problem,<br>
but I wanted to explain my view to ask: what is our goal? Why can&#39;t we<br>
try to follow the path we have already taken? Let&#39;s go on, after all,<br>
merging the repos is not such a big change!<br>
<br>
Cheers,<br>
Fabio<br>
</blockquote></div><br></div>