Is there a way we can deal with this better? It makes rawhide resyncs rather painful.
What's our strategy for removing locale subpackages for locales which have been removed upstream?
Thanks, Florian
On 05/09/2016 07:40 AM, Florian Weimer wrote:
Is there a way we can deal with this better? It makes rawhide resyncs rather painful.
If the resync adds a new locale, it will fail the rpm prep stage.
The key purpose is to avoid automatically creating subpackages by accident and uploading them.
Thus you must review the addition or removal of subpackages and then after review copy the new SUPPORTED file from the src tarball to dist-git. This resets the expected versus observed supported locales.
What's our strategy for removing locale subpackages for locales which have been removed upstream?
For a given stable release of Fedora we should not be removing a locale.
For Fedora Rawhide we should track what upstream does and remove the subpackage accordingly.
The user must have one langpack installed and we have a "Suggests" for glibc-all-langpack.
To be honest I haven't walked though the deprecation scenario in detail to see how dnf handles it, but I expect that if we remove a subpackage, that during the next upgrade dnf will use the "Suggests" and install glibc-all-langpack to satisfy the missing requirement for the upgrade.
I don't simpler solution?