Am 2007-03-11 12:21, Thorsten Leemhuis schrieb:
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"
I see the same problem with this.
* 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.
Since traffic doesn't cost the world anymore, I think this is acceptable.
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.
Still, we will have users who will complain, that they see that the
package has been build, but 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.
I think this is something that should be discussed on the next board
meeting; Shouldn't it? Someone from board on this list?
-of
