#2371 F33 System-Wide Change: Removal of the glibc-headers package
Closed: Accepted a month ago by bookwar. Opened 2 months ago by bcotton.

Replace the glibc-headers.i686 and glibc-headers.x86_64 package with a glibc-headers-x86.noarch package, and merge glibc-headers into glibc-devel on the other architectures.


So is glibc-headers-x86 happenning or there is some other solution which will happen?

I'd like to have composes fixed instead though. So I am ±0.

What do you mean by composes fixed? Introducing glibc-headers-x86 is one way of fixing the composes.

This issue has been with us for a very long time, and other approaches do not seem promising ways to fix the issue visible to end users (the broken upgrades).

Metadata Update from @churchyard:
- Issue tagged with: F33, system wide change

2 months ago

Questions/comments after reading the proposal and the releng issue it links to:

1) Why can't there be glibc-headers.i686 and glibc-headers.x86_64, but have the x86_64 contain the combined contents of both? Have glibc-headers.x86_64 Provide or Obsolete or whatever the glibc-headers.i686 one?

2) glibc-headers-x86.noarch does not sound like a good long term solution.

3) It's unclear to me if there will continue to be a glibc-headers package of some sort or if that's getting merged in to glibc-devel. That's the way I understand it.

Of these options, I would prefer glibc-devel and elimination of glibc-headers entirely. Is there an instance where you would want just the headers but not the devel package?

  1. During the x86_64 build, we do not have access to i686 build artifacts.

  2. Do you object to the glibc-headers-x86 name, or more generally to a package that is noarch merely due to its per-arch name?

  3. glibc-headers will be provided by glibc-devel because we still have some dependencies on it. x86_64 will end up with glibc-headers-x86 for the architecture-independent parts. Other architectures will merge glibc-headers into glibc-devel.

  4. Users need to be able to install both glibc-devel.x86_64 and glibc-devel.i686. If a file is provided by both packages (with identical content), I think RPM will still remove the file if only one of the packages installed is removed, breaking the system. I believe that's why the common files where moved to the glibc-headers package.

I'm not entirely sure about 4. Is this really how things behave?

$ dnf install python3-devel.i686
...

$ rpm -ql python3-devel.i686
...
/usr/include/python3.8/token.h
...

$ rpm -ql python3-devel.x86_64
...
/usr/include/python3.8/token.h
...

$ dnf remove python3-devel.i686
...

$ ls /usr/include/python3.8/token.h
/usr/include/python3.8/token.h

During the x86_64 build, we do not have access to i686 build artifacts.

Sure. My thinking is that the x86_64 package should also do setarch builds to also get the i686 artifacts it needs.

Do you object to the glibc-headers-x86 name, or more generally to a package that is noarch merely due to its per-arch name?

It says we are working around a deficiency in our packaging and build system. That we have a noarch package, but it's really arch-specific and we encode that in the name. It doesn't feel like a solution to me.

glibc-headers will be provided by glibc-devel because we still have some dependencies on it. x86_64 will end up with glibc-headers-x86 for the architecture-independent parts. Other architectures will merge glibc-headers into glibc-devel.

OK, I understand now (I think).

Users need to be able to install both glibc-devel.x86_64 and glibc-devel.i686. If a file is provided by both packages (with identical content), I think RPM will still remove the file if only one of the packages installed is removed, breaking the system. I believe that's why the common files where moved to the glibc-headers package.

Yeah, that's an unknown for me. Installation would work, but I am unsure what the behavior would be on removal. Best to not rely on it.

I understand we have limits in our packaging and build tools, but I don't like the approach of creating unusual package names. Going with the idea that x86 is a multilib platform, what I would expect as a user is that installing the x86_64 packages also gives me i686 files. Or at least I'm willing to make that concession for devel packages. What I would like to see:

  • glibc on i686 provide the existing runtime package that is i686 only.
  • glibc-devel on i686 provide the existing glibc-devel.i686 package and glibc-headers.x86_64 package content.
  • glibc on x86_64 provide the existing runtime package that is x86_64 only.
  • glibc-devel on x86_64 provide the existing glibc-devel.x86_64 and glibc-headers.x86_64 as well as the new glibc-devel.i686 package.
  • Only glibc-devel.x86_64 or glibc-devel.i686 can be installed at one time.

Installed results:
I have glibc.i686 and glibc-devel.i686 installed so I can run and build for i686.
I have glibc.x86_64 and glibc-devel.x86_64 installed so I can run and build for x86_64.
I have glibc.i686, glibc.x86_64 and glibc-devel.i686 installed so I can run for i686 and x86_64 but only build for i686.
I have glibc.i686, glibc.x86_64, and glibc-devel.x86_64 installed so I can run and build for i686 and x86_64.

Doing this would require duplicating the build of i686 artifacts for x86_64 in the spec file, but I think the end result is a cleaner set of packages. And yes, the i686 devel host would have unusable x86_64 devel files installed....another side effect that I don't think matters much here.

Another advantage to this setup is that I can always just rely on 'glibc-devel' as the correct devel package on i686 and x86_64.

The last point is true today and with my proposed changes (although I think we settled on depending on gcc or gcc-c++ to express this, but that's not relevant here).

I do not think your alternative proposal works. We will still need glibc-devel.i686 to provide the /usr/lib/libc.so file and (more importantly) the dependency on glibc.i686, which is required for 32-bit linking. We cannot add the dependency to glibc.x86_64 (even if our users were okay with it, which I doubt) because the x86_64 buildroot lacks glibc.i686.

Ah, right. The buildroot limitations too. OK, so amending my proposal, I would now do:

  • Add glibc-devel.i686 with the existing glibc-devel.i686 and glibc-headers.i686 content
  • Make glibc-devel.x86_64 conflict with glibc-devel.i686

This duplicates the i686 devel files across glibc-devel.i686 and glibc-devel.x86_64 but it would make the right files available in the i686 buildroot while also providing multilib devel capability in the x86_64 release. This may require manual intervention with tree composes to ensure glibc-devel.i686 does not end up in the x86_64 repo. But even if it did the RPM conflicts (or maybe obsolete) would prevent a dnf failure.

@dcantrell Sorry, I do not see how your latest proposal works.

I find it convenient to install the 32-bit environment using dnf install glibc-devel.i686. With the proposed conflict, I do not think this will work.

My original plan looks far less invasive to me, to be honest.

I was suggesting glibc-devel combine both the x86_64 and i686 devel files on x86_64 but only contain the i686 files on i686. On x86_64, glibc-devel would depend on both the x86_64 and i686 glibc packages. The tradeoff here is that the devel environment on x86_64 gives you both 64-bit and 32-bit. But by keeping glibc.x86_64 and glibc.i686 separate the runtime environments can be 64-bit or 32-bit only. Personally I think that's a reasonable tradeoff and gives package names that make sense from an end user's perspective.

This is a style preference. I like fewer packages especially when we don't support a complete i686 environment anyway. If you're building for i686, you're still running on x86_64 anyway. Why go to the trouble of splitting out all the i686 stuff still?

I understand if I'm in the minority here. Just wanted to state my preference here for a proposed solution and not wanting to see a package named glibc-headers-x86.

The tradeoff here is that the devel environment on x86_64 gives you both 64-bit and 32-bit.

I'm sorry, but I don't think this works well in the buildroot. True, we have glibc32 there, but I'd rather not put that into every C/C++ buildroot.

I'd appreciate if we move the discussion to the devel mailing list. Others might have things to say and they are not aware fo this discussion here.

I'm not entirely sure about 4. Is this really how things behave?

No, almost certainly not (as your test shows). If this was true, every package sharing files between subpackages would be broken.

Just wanted to state my preference here for a proposed solution and not wanting to see a package named glibc-headers-x86.

If this is a preference issue, and the maintainer prefers a specific option, we shouldn't push for a different one, unless there's a clear technical reason for prefer a different option. I agree with @fweimer that his plan less intrusive.

About the Change page:

Summary

It was always the intent that on Fedora for x86-64, only the glibc-headers.x86_64 was installed and available from composes. However, due to compose tool limitations, the glibc-headers.i686 package sometimes leaks into the compose, and end users my install it, causing future upgrade problems.

This is not a good Summary. It tries to answers the why? question, but doesn't say what will actually happen. We need a short description here that can be understood by users without going into the releng ticket. What the new package name will be, etc.

@zbyszek Fair enough about the summary. I have updated the Change accordingly, but I cannot edit the summary on this ticket.

Thanks.

but I cannot edit the summary on this ticket.

I don't think it matters.

I have updated the Change accordingly, but I cannot edit the summary on this ticket.

But I can (and did)!

@fweimer thanks for the discussion here and humoring me on my ideas. My main concern was on the end user experience and the names of packages and what may end up on the installed system. I wish we had a bit more flexibility in rpm with regards to noarch subpackages and dependencies, but here we are. I've given my thoughts on the matter, but I don't want to delay this work.

I'm +0 on this one.

After one week, I count the vote as (+1,2,-0). Waiting for further votes. (Note that no further discussion has occurred on devel since 3 April)

I could have sworn I voted +1 earlier today, but I must have forgotten to submit the comment.

Unfortunately I won't have time to examine this properly. I abstain. If that would be the only reason this is not approved (unlikely), I'll find the time.

Metadata Update from @bookwar:
- Issue tagged with: meeting

a month ago

I have re-read change proposal again and I think I am fine with it.

+1.

With FESCo votes from yesterday and Igor's vote

the change is APPROVED (+7, 2, 0)

Metadata Update from @bookwar:
- Issue untagged with: meeting
- Issue tagged with: pending announcement

a month ago

Metadata Update from @bookwar:
- Issue untagged with: pending announcement

a month ago

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

a month ago

Login to comment on this ticket.

Metadata