#8337 glibc-headers-2.29-12.fc30 i686 erroneously in x86_64 GA repo
Opened 4 years ago by mooninite. Modified 5 months ago

  • Describe the issue
    This appears to be a mashing problem for multilib with glibc-headers.

glibc-headers-2.29-9.fc30.i686
glibc-headers-2.29-9.fc30.x86_64

Both exist in the x86_64 repo for the 'fedora' repo, but the first glibc update released to the 'updates' repo is missing the i686 package.

Bodhi update: https://bodhi.fedoraproject.org/updates/FEDORA-2019-f82f6f0c87


The i686 package is not needed, but since it was in the F30 GA compose, some people may have installed it.

Ideally, the package would not be there, but if it is consistently included, this is also fine.

Hm, yeah... this is messy. It requires manual intervention to fix. Thanks for the pointer to the bug, but releng may still need to be involved to fix the repos unless you want to add an Obsoletes: i686 headers package to the x86_64 headers package. I've updated this ticket title.

Metadata Update from @syeghiay:
- Issue assigned to mohanboddu

4 years ago

ok, so I would love to fix this once and for all.

I guess the two options are:

  • Figure out what is pulling it into the base repo and fix those packages.
    dnf repoquery says:
glibc-devel-0:2.31.9000-4.fc33.i686
glibc-devel-0:2.31.9000-4.fc33.x86_64
libattr-devel-0:2.4.48-8.fc32.i686
libattr-devel-0:2.4.48-8.fc32.x86_64
libecb-devel-0:0.20190722-3.fc32.i686
librichacl-devel-0:1.12-9.fc32.i686
vcglib-0:1.0.1-2.fc32.i686
vcglib-0:1.0.1-2.fc32.x86_64

Can we fix those to only requre glibc-headers.%{isa}?

Or

  • We adjust the updates pungi to always include this. I guess this is the prepopulate that @lsedlar mentioned.

@fweimer do you have a pref? Do you think the packages can be fixed? Or is there some reason it should get pulled in?

@kevin Not sure how you determined the list of affected packages. We cannot change glibc-devel. There is a necessary variance here: the i686 buildroot pulls in glibc-devel.i686 and glibc-headers.i686, but on an x86_64 compose-based installation, it should be glibc-devel.i686 and glibc-headers.x86_64.

The other packages simply should not have a dependency on glibc-headers. That part can be fixed.

We could perhaps rename glibc-headers to glibc-headers-x86 on x86_64 and i686 and make that package noarch. Would that help?

@kevin Not sure how you determined the list of affected packages. We cannot change glibc-devel.

Just dnf repoquery on a x86_64 machine...

There is a necessary variance here: the i686 buildroot pulls in glibc-devel.i686 and glibc-headers.i686, but on an x86_64 compose-based installation, it should be glibc-devel.i686 and glibc-headers.x86_64.

? Should that second one be glibc-devel.x86_64 and glibc_headers.x86_64?

The other packages simply should not have a dependency on glibc-headers. That part can be fixed.

yeah.

So the desired state is:

a) no glibc-headers.i686 in the base repo or in updates/updates-testing

or

b) glibc-headers.i686 is in the base repo and always updates/updates-testing (if there is a glibc update in there).

either one right?

We could perhaps rename glibc-headers to glibc-headers-x86 on x86_64 and i686 and make that package noarch. Would that help?

I think this might work. Since there would no longer be a .i686 and .x86_64 versions of that subpackage it would just use it (once)

We could also do 'b' above in pungi by telling it to always include glibc-headers.i686 in the updates composes.

Do you want to try your idea and we can see if it works? if not, we can just revert it and go with the pungi hammer?

I'm not sure if these repoquery results are accurate.

If you install the 32-bit C/C++ development on an x86_64 machine, you are expected to get glibc-devel.i686 and glibc-headers.x86_64 (in addition to glibc-devel.x86_64 for the 64-bit environment). I think I got that part right …

(a) or (b) should work, yes. (a) is better for alignment with downstream, I guess.

Yes, I can try the noarch approach in rawhide (and fix up the packages that are not compatible with it).

I implemented this locally and it seems to work (still ironing out a few issues). I've submitted a Change proposal: https://fedoraproject.org/wiki/Changes/RemoveGlibcHeaders

A new glibc package is now built with the proposed changes

https://koji.fedoraproject.org/koji/buildinfo?buildID=1499075

We will verify it tomorrow and close this ticket if its fixed.

Metadata Update from @cverna:
- Assignee reset

3 years ago

This is fixed. Please re-open if you see anything further to do here.

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

3 years ago

@kevin You mean, the issue is worked around in glibc, right?

The noarch hack unfortunately has its own set of bad side effects, but they seem to impact end users less and are at least 100% predictable, so unless the infrastructure issue has been identified & fixed, I guess we have to stick to it. 8-(

Well, if there's bad side effects to that, we can do it on the infra side.

I think it just needs us blocking glibc-headers from being multilib on x86_64 in both pungi-fedora (for rawhide) and infrastructure ansible (for updates).

Would you like us to try that in rawhide?

Metadata Update from @kevin:
- Issue status updated to: Open (was: Closed)

3 years ago

rawhide doesn't have an updates repository, so we don't know if things are fixed if it works there.

We implemented the noarch hack after years of occasional breakage. If you are confident that you can make the glibc-headers problem go away on the infrastructure side, then please do so. No one else has been able to. I'm very much in favor of removing the noarch hack if we can.

I think we can... but perhaps I could get @lsedlar to chime in here?

Would it work to put glibc-headers in multilib blacklist for rawhide/branched and bodhi pungi config? ie, never ship glibc-headers.i686 in the x86_64 repos at all?

I would think it would, but I might be missing something now.

ok, so where are we here?

Would you like us to try the blocklist? Or is the workaround sufficent that we can just stay with it?

@kevin Is this question directed at me? 8-)

I would still very much like to get rid of the noarch packages. Filtering glibc-headers.i686 from the x86_64 compose should work as a stop-gap, I assume, even if the underlying tooling issue has not been addressed.

Actually it was more addressed to @lsedlar I guess, but you input is welcome too. :)

In the previous ticket we were looking at ways to always ship glibc-headers.i686 in x86_64 repos, but it seems like we would prefer to not ship it anywhere ?

I am not sure what the underlying tooling issue is here. I think pungi is doing what we tell it to do, and we just need to tell it to do the right thing. ;)

So, can we just add this to multilib_blacklist and be done? I think it's too late to do this for f37, but could we start in rawhide and carry that into f38 after branching?

I can add this to pungi for rawhide and then you can undo the noarch thing, then we can confirm it's not shipping there anymore?

Then we will need to make sure to also adjust config when we branch.

I think we should make these changes for rawhide/f38 as you propose, and see how it goes.

Sorry for the stale here, is this something that is required? If so we can implement the plan from the previous comment by nirik for the current rawhide.

Login to comment on this ticket.

Metadata