Multilib inconsistencies between fedora/updates/updates-testing composes

[Florian Weimer]

We have seen reports that glibc-headers.i686 comes and goes from the
x86_64 updates compose.  Previously, we have seen this only for the
updates-testing compose: <https://pagure.io/releng/issue/7071>

This leads to a very bad update experience.  Users file bugs against the
glibc package, but I don't think we can do anything on our side, at
least not until we know what the actual compose bug is and what triggers
it.

Thanks,
Florian

[Tom Stellard]

On 12/12/2018 02:32 AM, Florian Weimer wrote:
>  We have seen reports that glibc-headers.i686 comes and goes from the
>  x86_64 updates compose.  Previously, we have seen this only for the
>  updates-testing compose: <https://pagure.io/releng/issue/7071>
>  
>  This leads to a very bad update experience.  Users file bugs against the
>  glibc package, but I don't think we can do anything on our side, at
>  least not until we know what the actual compose bug is and what triggers
>  it.
>   
We've seen this same problem with the compiler-rt package for the last
few releases:

https://bugzilla.redhat.com/show_bug.cgi?id=1513286
https://bugzilla.redhat.com/show_bug.cgi?id=1615016

-Tom

>  Thanks,
>  Florian
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Florian Weimer]

* Florian Weimer:

>  We have seen reports that glibc-headers.i686 comes and goes from the
>  x86_64 updates compose.  Previously, we have seen this only for the
>  updates-testing compose: <https://pagure.io/releng/issue/7071>
>
>  This leads to a very bad update experience.  Users file bugs against the
>  glibc package, but I don't think we can do anything on our side, at
>  least not until we know what the actual compose bug is and what triggers
>  it. 
We really need to fix this issue, it breaks updates for many users.

Any suggestion how we can move this forward?

Thanks,
Florian

[Kevin Fenzi]

On 12/14/18 4:06 AM, Florian Weimer wrote:
>  * Florian Weimer:
>  
> > We have seen reports that glibc-headers.i686 comes and goes from the
> > x86_64 updates compose.  Previously, we have seen this only for the
> > updates-testing compose: <https://pagure.io/releng/issue/7071>
> >
> > This leads to a very bad update experience.  Users file bugs against the
> > glibc package, but I don't think we can do anything on our side, at
> > least not until we know what the actual compose bug is and what triggers
> > it.
>  
>  We really need to fix this issue, it breaks updates for many users.
>  
>  Any suggestion how we can move this forward? 
I had another question for lsedlar, but the prepopulate might work. That
means we bloat our updates/updates-testing repos by all the .i686 stuff
that was in the GA repo, but at least it means it will always be there.

This also would mean it would require changing this list if someone
changed a package in a update such that it was no longer multilib, but
hopefully that doesn't happen too often.

kevin

[Carlos O'Donell]

On 12/14/18 1:50 PM, Kevin Fenzi wrote:
>  On 12/14/18 4:06 AM, Florian Weimer wrote:
> > * Florian Weimer:
> >
> >> We have seen reports that glibc-headers.i686 comes and goes from the
> >> x86_64 updates compose.  Previously, we have seen this only for the
> >> updates-testing compose: <https://pagure.io/releng/issue/7071>
> >>
> >> This leads to a very bad update experience.  Users file bugs against the
> >> glibc package, but I don't think we can do anything on our side, at
> >> least not until we know what the actual compose bug is and what triggers
> >> it.
> >
> > We really need to fix this issue, it breaks updates for many users.
> >
> > Any suggestion how we can move this forward?
>  
>  I had another question for lsedlar, but the prepopulate might work. That
>  means we bloat our updates/updates-testing repos by all the .i686 stuff
>  that was in the GA repo, but at least it means it will always be there. 
Yes please. Consistency is the key here. Either all gone, or all there.
 
>  This also would mean it would require changing this list if someone
>  changed a package in a update such that it was no longer multilib, but
>  hopefully that doesn't happen too often. 
This is so rare I've never observed it ;-)

-- 
Cheers,
Carlos.

[Dennis Gilmore]

https://pagure.io/releng/issue/4084 its an issue that has existed for
nearly a decade and not been solved. Time was not taken to fixing it
after we disabled installing multilib by default as there was no
reports of it for years.

Dennis

El mié, 12-12-2018 a las 11:32 +0100, Florian Weimer escribió:
>  We have seen reports that glibc-headers.i686 comes and goes from the
>  x86_64 updates compose.  Previously, we have seen this only for the
>  updates-testing compose: <https://pagure.io/releng/issue/7071>
>  
>  This leads to a very bad update experience.  Users file bugs against
>  the
>  glibc package, but I don't think we can do anything on our side, at
>  least not until we know what the actual compose bug is and what
>  triggers
>  it.
>  
>  Thanks,
>  Florian
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: 
>  https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives: 
>  https://lists.fedoraproject.org/archives/list/[e-mail]