[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [atomic-devel] [fedora-atomic f23] remove Python source files
- From: Fabian Deutsch <fdeutsch redhat com>
- To: Daniel J Walsh <dwalsh redhat com>
- Cc: Giuseppe Scrivano <gscrivan redhat com>, atomic-devel projectatomic io
- Subject: Re: [atomic-devel] [fedora-atomic f23] remove Python source files
- Date: Thu, 3 Dec 2015 15:10:18 +0100
On Thu, Dec 3, 2015 at 3:00 PM, Daniel J Walsh <dwalsh redhat com> wrote:
>
>
> On 12/03/2015 06:49 AM, Fabian Deutsch wrote:
>> On Thu, Dec 3, 2015 at 12:25 PM, Giuseppe Scrivano <gscrivan redhat com> wrote:
>>> Fabian Deutsch <fdeutsch redhat com> writes:
>>>
>>>> On Wed, Dec 2, 2015 at 1:54 PM, Giuseppe Scrivano <gscrivan redhat com> wrote:
>>>>>> The removal caused some trouble:
>>>>>> - removing informations from drawbacks
>>>>>> - Making debugging - testing changes - very cumbersome
>>>>>> - Breaks "plugin" mechanisms of a surprising large number of tools
>>>>>>
>>>>>> In our next release we will finally re-introduce .py files again:
>>>>>> Bug 1233106 - [RFE] Remove all kernel, firmware, and .py file blacklisting
>>>>>>
>>>>>> I'd suggest to consider and not underestimate these factors.
>>>>> thanks for the feedbacks. Were .pyc files used instead of the .py
>>>>> version in oVirt?
>>>> We dropped .py and .pyc files - so the .pyo files were kept.
>>>>
>>>>> IIUIC, pyc files maintain the same information as the
>>>>> original source file, while .pyo files are a optimized version that has
>>>>> not all the original content. Using the optimized version, I could
>>>>> strip 55 MB of space from the Fedora Atomic image, if I use .pyc then
>>>>> the reduction is only 27 MB.
>>>> What about keeping .py and .pyo, and just drop .pyc?
>>> That could be an option. The image size I got keeping .py and .pyo is
>>> 15 MB smaller than the original one.
>> Nice. Not as much as 55MB, but still a win.
>>
>> - fabian
>>
> Will this work on an SELinux system? Will python attempt to create the
> pyc files, when the code is executed?
> SELinux would stop a confined domain from writing to /usr of course, but
> might generate AVC's. If the file system
> is read/only then it would be a matter of whether the SELinux checks
> happen first or second.
I don't have experience with the SELInux beahvior in this case, as we
used a read-only rootfs - which prevented python from creating files
there.
- fabian
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]