+1 for --isolation
st 18. 9. 2019 v 15:33 odesílatel John Florian <jflorian(a)doubledog.org
<mailto:jflorian@doubledog.org>> napsal:
On 9/11/19 6:14 AM, Vít Ondruch wrote:
> Dne 11. 09. 19 v 11:56 Miroslav Suchý napsal(a):
>> Please comment there:
>>
>>
https://github.com/rpm-software-management/mock/issues/331
<
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_rpm-2Dsof...
>>
>> Copy of Comment #0:
>> This is Request For Comments.
>>
>> When systemd-nspawn has been added to mock, it brought a lot of
bugs. For the transition period we introduced
>> --old-chroot and --new-chroot. The intent was to steer toward
the new chroot as mock running containers is more secure
>> and everything. And maybe one day allow choosing between
nspawn, docker, podman and others.
>>
>> But the world went another way. When people are interested in
containers, they usually do not want mock to run a
>> container, but they run mock inside of a container. When mock
is running inside of container then there is no need for
>> additional isolation and no one really wants to run another
container inside of a container. Therefore the --old-chroot
>> is a good choice when you run inside of a container.
>>
>> My intention is to keep --old-chroot indefinitely and actually
recommend it when mock is running in a container. And
>> maybe later automatically choose old or new one depending on if
mock is running in a container or on bare metal.
>>
>> In this situation, the names old/new are quite misleading. As
it hints that you should rather use the new stuff rather
>> than the old ones.
>>
>> Therefore I want to rename (in fact, make alias) for those
command-line options.
>>
>> --old-chroot -> --simple-chroot
>> --new-chroot -> --container-chroot ??? I want to avoid
confusion here whether this option use container for chroot
>> (nspawn) or it is recommended to use when running in container.
>>
>> I would like to hear your comments and ideas.
>>
> My first idea was:
>
> --old-chroot -> --chroot
> --new-chroot -> --container
>
> But that is probably the confusion you are talking about. So
should you
> change this to something like `--isolation=[chroot,nspawn]`? At
the and,
> there are tools/technologies such as chroot and nspawn, which mock
> facilitates to "isolate" (of course we can debate what level of
> isolation chroot provides ...) the build environment from the
rest of
> the system.
I like the idea of `--isolation=`. To me this affords the best
clarity and also makes room for values of {none,{auto|detect}} or
whatever as well should those ever seem appropriate.
_______________________________________________
buildsys mailing list -- buildsys(a)lists.fedoraproject.org
<mailto:buildsys@lists.fedoraproject.org>
To unsubscribe send an email to
buildsys-leave(a)lists.fedoraproject.org
<mailto:buildsys-leave@lists.fedoraproject.org>
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
<
https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.o...
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
<
https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wi...
List Archives:
https://lists.fedoraproject.org/archives/list/buildsys@lists.fedoraprojec...
<
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject....
--
Tomas Kopecek <tkopecek(a)redhat.com
<mailto:tkopecek@redhat.com>>
Release Engineering Development, RedHat
_______________________________________________
buildsys mailing list -- buildsys(a)lists.fedoraproject.org
To unsubscribe send an email to buildsys-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.o...
List Guidelines:
https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wi...
List Archives:
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject....