Could the koji buildroot be fixed up to always include glibc-gconv-extra alongside glibc?

Why not adding the requirement to the package? Like here https://src.fedoraproject.org/rpms/glibc/c/c20fde6a69e73fd208df64f92a2bc221f058dfed?branch=rawhide but in glibc package?

If we add a strong dependency, it can't be uninstalled. If we add a weak dependency, Fedora's mock won't install it, requiring action from too many package maintainers.

What about local mock builds, wont they fail? Also, does it need to be added in buildsys-build group in comps? And is it for just srpm-build or build or both?

Yes, local mock builds would also fail, it just didn't occur to me because I don't use it much :)

I just looked up comps.xml and yes, buildsys-build in comps seems like the right place for this. Packages seem to use the converters in their tests or in pre/post scripts, so I reckon build should be sufficient.

Please no. We drop various things from the buildroot (gcc, make, glibc-all-langpacks, …), and this is no different. Please identify the packages that need that and add BuildRequires in them.

@zbyszek To be clear, this is not about adding things to the buildroot. The codecs are presently included. All we want is giving system administrators (not packagers) an option not to install them on their systems.

It's very hard to identify packages which have a build dependency on codecs because several such packages will just disable functionality transparently if required codecs are unavailable. So just watching for build failures won't work. Fedora builds are generally not reproducible, and manual comparison of the output with and without the codecs is very cumbersome.

It's very hard to identify packages which have a build dependency on codecs because several such packages will just disable functionality transparently if required codecs are unavailable.

Can you give examples of this? The reports I saw on fedora-devel were about iconv() failing, and the whole build failing.

All we want is giving system administrators (not packagers) an option not to install them on their systems.

IMO, it is better to make the dependency explicit in packages that need it. In particular, with the approach that it's included automagically in buildroot, but not declared, means that local builds with fedpkg local might not work properly.

The fraction of package that require codecs is certainly miniscule, and dropping them from the build root makes it a bit smaller. It seems better to do this now (since people are already aware of the change), than to pull it back in, and then go through another removal later on.

If we add Requires: (glibc-gconv-extra%{?_isa} = %{version}-%{release} if redhat-rpm-config) to glibc, system administrators (not packagers) will get an option not to install them on their systems.

@churchyard We did that for glibc-all-langpacks because packagers are already accustomed to that package. Perhaps that would be a middle-ground between buildroot minimization and packager inconvenience.

However, I wasn't sure if these kind of rich dependencies involving redhat-rpm-config are appropriate (from a policy point of view).

Could the koji buildroot be fixed up to always include glibc-gconv-extra alongside glibc?

Why not adding the requirement to the package? Like here https://src.fedoraproject.org/rpms/glibc/c/c20fde6a69e73fd208df64f92a2bc221f058dfed?branch=rawhide but in glibc package?

Please, correct me if I'm wrong. This is what we currently have in rawhide with v2.33.9000-23, but glibc-gconv-extra is not being pulled in Copr and packages are failing, e.g.: https://download.copr.fedorainfracloud.org/results/iucar/cran/fedora-rawhide-x86_64/02296756-R-CRAN-affluenceIndex/builder-live.log.gz

However, I wasn't sure if these kind of rich dependencies involving redhat-rpm-config are appropriate (from a policy point of view).

They are. We usually conventionalize on rpm-build in Python because I think more people are likely to accidentally pull in the small config package, but there is no rule about this.

See pyton3-devel:

$ rpm -q --requires python3-devel
(python-rpm-macros if rpm-build)
(python3-rpm-generators if rpm-build)
(python3-rpm-macros if rpm-build)
(python3-setuptools if rpm-build)
...

Please, correct me if I'm wrong. This is what we currently have in rawhide with v2.33.9000-23...

In the glibc-all-langpacks package. I suggested to put it into the glibc package.

@iucar It's not clear from the diff, but this requirement was only added to glibc-all-langpacks subpackage, which Fedora doesn't want in the general buildroot. There are quite a few packages that need charset processing, but currently do not depends on glibc-all-langpacks.

Please, correct me if I'm wrong. This is what we currently have in rawhide with v2.33.9000-23...

In the glibc-all-langpacks package.

Ok, I see.

I suggested to put it into the glibc package.

Agree.

If we add Requires: (glibc-gconv-extra%{?_isa} = %{version}-%{release} if redhat-rpm-config) to glibc, system administrators (not packagers) will get an option not to install them on their systems.

FWIW, adding a conditional dependency on redhat-rpm-config is mostly functionally equivalent to adding glibc-gconv-extra to buildsys-build. The only difference is that someone using redhat-rpm-config for some reason is forced to have glibc-gconv-extra on their system. That's not too bad a problem AFAICT, we can live with it.

I'm fine with this if it's the consensus; it gives the glibc team additional control over this.

I really don't want glibc-gconv-extra to be an explicit dependency because we won't know about the silent failures without trawling through every build log of a mass rebuild. Getting glibc-gconv-extra into all buildroots maintains the status quo (it's already in there after all) and is the least invasive change.

I really don't want glibc-gconv-extra to be an explicit dependency because we won't know about the silent failures without trawling through every build log of a mass rebuild.

I don't understand this bit. How is that different from adding it to the buidlroot in this regard?

I really don't want glibc-gconv-extra to be an explicit dependency because we won't know about the silent failures without trawling through every build log of a mass rebuild.

I don't understand this bit. How is that different from adding it to the buidlroot in this regard?

What I mean is that to add an explicit build dependency in specific packages, we would have to do a mass rebuild without glibc-gconv-extra in the buildroot and then find out which packages fail. They may either fail noisily, e.g. like Python did with its tests or the other packages that reported failures or they may ignore the iconv() failures and either build with a limited feature set (as Florian described) or just broken in ways that we'll find later. This process is too lenghty and error prone and I'd like to avoid it if we can and simply get glibc-gconv-extra into all buildroots.

Thanks for clarifying, I understand this now.

So, everyone okay with adding conditional dependency on redhat-rpm-config? In that case, releng has nothing to do with this ticket and close it?

@mohanboddu I think we can close this. We will add the conditional dependency on redhat-rpm-config in glibc.