Alpha Core 3 is available

[Thorsten Leemhuis]

Toshio Kuratomi schrieb:
> On Sat, 2007-03-10 at 16:47 +0100, Thorsten Leemhuis wrote: 
>> Oliver Falk schrieb:
>>> Thorsten Leemhuis schrieb:
>>>> Users of i386 and x86_64 that update daily would have had two package
>>>> updates without any benefit for them :-( I'd like to aoid that if easily
>>>> possible.
>>> Thorsten; Very good point, didn't even think about this possibility... 
>>> Maybe some extra step from (co-)maintainers and/or sub-arch maintainers 
>>> is needed here to finally push the package!?
>> I think with the new updates system luke is working on we'll get a
>> seperate "push" step for each package (correct me if I'm wrong) . We
>> just need to tell packagers to wait a bit with pushing their packages in
>> case build failed one some of the secondary archs.
> Alternately, we might decide that it's sane not to push every update to
> every arch.  So a commit by a secondary arch might be built for x86_64
> and i386 but not pushed to the update repo.  Note that I haven't thought
> long and hard about whether this is sane, just that if it is sane, it
> would be another way of taking care of the problem.

I have thought about this alternative as well, but I fear

 * questions like "Why is package foo in sparc newer than in i386"

 * that we have a lot of scripts (the repo cleanup scripts for example)
afaics that work by looking at the srpms, which might lead to situations
where a i386/x86_64 package is still in the repo, but the srpms is
missing; or even worse, the i386/x86_64 packages might gets removed...

> This could come into play for security updates.  In that case, we'd want
> to build and push as quickly as possible.  A secondary arch that had a
> broken build as a result would want to fix and rebuild as quickly as
> they could.  Not pushing for the primary arch in that case would allow
> us to avoid the double download.

I'd say in such a case it might be acceptable that the primary arch
users update the package once without having a benefit.

> On the debit side, this kind of thing means that a maintainer might make
> a release that runs on the primary arches.  Then a secondary arch
> commits a fix for their arch and builds but the fix causes runtime bugs
> for the primary arch (buildtime will be caught because we'll build for
> all arches anyway.)  This won't be caught until the next time the
> primary arch is updated and pushed....

Another good point... But well, the package could be build, just not pushed.

Anyway, the scripts could be fixed if we want to go this route. That
would leave only the "Why is package foo in sparc newer than in i386"
problem.

CU
thl