From: Bruce Ashfield <bruce.ashfield@gmail.com>
To: Ming Liu <liu.ming50@gmail.com>
Cc: meta-virtualization@lists.yoctoproject.org
Subject: Re: [meta-virtualization][PATCH] podman: support bash completions for podman/docker
Date: Wed, 10 Jan 2024 09:08:15 -0500 [thread overview]
Message-ID: <CADkTA4Oi3fAiOwwj5Zd-Cyqu==gxSQiiTsTDDSQ=7tQUrPqnag@mail.gmail.com> (raw)
In-Reply-To: <CALatG=7B5bHVustExrSgUiWsWMGLqFz6Gi9VZ6qyaUzYvomLSg@mail.gmail.com>
On Wed, Jan 10, 2024 at 3:50 AM Ming Liu <liu.ming50@gmail.com> wrote:
>
> Hi, Bruce:
>
> Got that, in that case, I will use a bbappend in our meta layers for now, thanks for the explanation.
>
> About the podman-native recipe you mentioned, do you plan to push it to meta-virtualization layer? We found it's very useful in some cases, I am also considering adding native/natiesdk for buildah, it could be used to provide a fakerooted build env.
>
I will push both of the changes eventually, I'm currently still
working through some pseudo and
namespace / cgroups problems.
I also have buildah as native in that scenario, since it is slightly
coupled to podman. But I won't
use it as a image construction method as it duplicates far too much
code from other tools and
had it's own set of assumptions and coupling.
Bruce
> the best,
> thank you
>
> Bruce Ashfield <bruce.ashfield@gmail.com> 於 2024年1月9日 週二 下午2:23寫道：
>>
>> On Tue, Jan 9, 2024 at 4:19 AM Ming Liu <liu.ming50@gmail.com> wrote:
>> >
>> > Hi, Bruce:
>> >
>> > Seems podman manage its shell completions inside the code (see this line: https://github.com/containers/podman/pull/21095/commits/6c4892c8029fd992b4494adb62c535d0f5c5d62d#diff-cf5cc76e70a369c5221f08f29ec0452710af1f4ecd423c162d5b669688416caeR484)
>> >
>> > then it uses "podman completion SHELL-NAME" to get the completion for a particular shell, so it's not safe to pre-generate a completion outside of podman source? For instance, if we add a CVE fix or some common bug fixes to SRC_URI, the completion might be changed and the developers have to be aware of that and also update completion file.
>> >
>>
>> That CVE example is quite unlikely .. and I'd suggest we created the
>> issue by packaging the completions in the first case.
>>
>> > And this qemu wrapper way is being used in OE in several recipes, like python, the qemu-native would be built in most cases if you build a OE image, so would be no much cost on it? Just my personal options.
>> >
>>
>> I'm quite aware of how and where the wrappers are used. It is still
>> too complex for something as trivial
>> as bash completion generation.
>>
>> I'd suggest you can carry the generation and packaging in a bbappend,
>> and that I can look into alternate
>> ways to generate the completions in the future.
>>
>> Even generating them on-target, in a first boot scenario is preferable
>> (from a maintenance point of view).
>>
>> I also have a podman-native extension locally that could be useful,
>> but doing an emulated arch-specific
>> execution of target podman to generate bash completion outputs (that
>> should NOT be arch specfic, and
>> if they are, we want no part of them) is far too heavy.
>>
>> Bruce
>>
>> > the best,
>> > thank you
>>
>>
>>
>> --
>> - Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end
>> - "Use the force Harry" - Gandalf, Star Trek II
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
prev parent reply other threads:[~2024-01-10 14:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-08 18:09 [meta-virtualization][PATCH] podman: support bash completions for podman/docker liu.ming50
2024-01-08 18:22 ` Bruce Ashfield
2024-01-09 9:19 ` Ming Liu
2024-01-09 13:23 ` Bruce Ashfield
2024-01-10 8:50 ` Ming Liu
2024-01-10 14:08 ` Bruce Ashfield [this message]
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='CADkTA4Oi3fAiOwwj5Zd-Cyqu==gxSQiiTsTDDSQ=7tQUrPqnag@mail.gmail.com' \
--to=bruce.ashfield@gmail.com \
--cc=liu.ming50@gmail.com \
--cc=meta-virtualization@lists.yoctoproject.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).