[pve-devel] [PATCH pve-widget-toolkit] Changed 'kr' to 'ko' in language list

Thomas Lamprecht t.lamprecht at proxmox.com
Mon Mar 27 10:15:07 CEST 2023


Am 27/03/2023 um 09:58 schrieb Fabian Grünbichler:
> 
>> Thomas Lamprecht <t.lamprecht at proxmox.com> hat am 26.03.2023 16:51 CEST geschrieben:
>>
>> In widget-toolkit we do not depend on any i18n package as widget-toolkit is
>> also used in more than one project; adding an OR'd `pve-i18n | pmg-i18n |
>> pbs-i18n` could work but is a bit of a PITA as some tools will use the first
>> one here (e.g.  debootstrap) if one isn't careful.  So, we could instead add a
>> virtual proxmox-widget-toolkit-i18n package that all pmg/pve/pbs- i18n ones
>> provide as $binary:version and make proxmox-widget-toolkit depend on that;
>> would be IMO slightly cleaner.
> 
> IIRC having just a Depends: on a virtually-provided package provided by more than one actual package is even worse with regards to tooling support (hence the Debian policy of always depending on "actual-package | virtual-package", like "initramfs-tools (>= 0.120+deb8u2) | linux-initramfs-tool", or "uniquely-provided-virtual-package | virtual-package", like "default-mta | mail-transport-agent" to express a preference, and the corresponding behaviour in debootstrap and buildd to only look at the first arm of an ORed dependency).

hmm, scratch the virtual package; we could really produce the package including
translations for widget-toolkit hosted translations though.

Actually it could be move to a dev dependency that every package using gettext
depends on and will use to produce the respective filtered out translation list
for their code, that way we could easier re-use it on other non-JavaScript UI's
too; but certainly a bigger change.

> 
> Also, Provides/virtual packages are not really a good fit for this problem, since the packages don't provide the same thing and proxmox-widget-toolkit also cannot use them interchangeably (i.e., on PVE having pmg-i18n installed is a nop and doesn't help at all, but it would satisfy the dependency).
> 

that's not true, *all* packages (as they are now) satisfy the translation
requirements from *proxmox-widget-toolkit*, and pmg-gui would then have the
more explicit dependency on pmg-i18n anyway.

> I think in this case the solution would be to add Breaks to both/all involved packages for the old version (so that no combination of new+old can be installed) and add bumped versioned dependencies higher up the stack (e.g., pve-manager) to force the upgrade - if we want to have this transition, that is ;)
>
Yeah, that's certainly a solution as mentioned, but I'd rather look at this
in the next major release; maybe rework packaging a bit to make it a better
fit for the depending packages.





More information about the pve-devel mailing list