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
_______________________________________________
axp-list mailing list
axp-list redhat.com
http
s://www.redhat.com/mailman/listinfo/axp-list
|
