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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.