From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: "Proxmox VE development discussion" <pve-devel@lists.proxmox.com>,
"Fabian Grünbichler" <f.gruenbichler@proxmox.com>,
"Noel Ullreich" <n.ullreich@proxmox.com>
Subject: Re: [pve-devel] [PATCH pve-widget-toolkit] Changed 'kr' to 'ko' in language list
Date: Mon, 27 Mar 2023 10:15:07 +0200 [thread overview]
Message-ID: <6b8437c1-6e4a-84c8-b5bf-34ec7a7ff92b@proxmox.com> (raw)
In-Reply-To: <550198115.1827.1679903911278@webmail.proxmox.com>
Am 27/03/2023 um 09:58 schrieb Fabian Grünbichler:
>
>> Thomas Lamprecht <t.lamprecht@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.
next prev parent reply other threads:[~2023-03-27 8:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-24 14:41 Noel Ullreich
2023-03-26 14:51 ` Thomas Lamprecht
2023-03-27 7:58 ` Fabian Grünbichler
2023-03-27 8:15 ` Thomas Lamprecht [this message]
2023-03-27 8:28 ` Fabian Grünbichler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6b8437c1-6e4a-84c8-b5bf-34ec7a7ff92b@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=f.gruenbichler@proxmox.com \
--cc=n.ullreich@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox