On Thu, 4 Oct 2018, Robert Schweikert wrote:
On 10/4/18 1:33 PM, Thorsten Kukuk wrote:
On Thu, Oct 04, Robert Schweikert wrote:
Can you share the definition of "small and slim". What is the target size we want to get to and why does it matter if the image is a "bit" bigger?
Ever downloaded an image at every boot via LTE? That's what some of our customers are doing, as they don't want to send technicians out in the wild to do that via usb stick.
And in virtualisation environments (not public cloud), disks are no longer cheap, as you have many, many virtual machines. So why for you a jump from 8 GB to 10 GB in the public cloud is no big problem, a lot of customers would like to see that we use only 4 GB,
But we can build a 4GB functional openSUSE or SLES image with pyc code included, I'm pretty sure. Our images in the Public Cloud are 10GB on the request of the providers, not because we need the space.
as that would allow them to store double as many virtual machines as today. And the LTE fraction would even like to see images in the 150MB range...
I see the problem with that request.
Having these numbers is interesting but what is the goal of the image you want to build and what is the benefit of the smaller size for JeOS or MicriOS?
The requested goal by our big customers are less than 500MB, else see above.
And no, we don't want any of your proposed hacks, we are very happy that we were able to remove all of this hacks from building images. This only breaks RPM and updating the images.
OK, fair enough, although I do not consider image manipulation via images.sh a hack, I agree that it will cause issues with the update path. Then again an image that gets downloaded for every boot should get rebuilt for updates, rather than being updated in place.
So we have two groups with seemingly conflicting interests that we'll try to make happy without favoring one at the expense of the other. We've been here before ;)
Can we teach rpm to handle this better? I am thinking of something like
--no-pycache
as an option for install. This would skip the install of pyc/pyo, egg, and other Python artifacts and leave a record in the rpmdb that the package was installed with this option. Then it could be handled in the update path properly and not install the byte compiled files on update, nor try to remove them from the previous package install. Of course there needs to be an option to get the "missing" files, maybe something like "--add-pycache".
For MicroOS and JeOS image builds this could then be set as an option for the kiwi image build, well kiwi would need to learn about the new option, but that is not too terribly difficult. We might need to introduce a macro to mark the files in the rpm package appropriately, maybe something like
{%_pycache_file}
The concept already exists in rpm (--excludedocs) to piggy back on. But I certainly don't know enough about the state of the rpm community if something like this would fly upstream or if this is something we'd consider doing on our own.
mls?
Something along those lines would meet both of our needs.
Well, I suppose first splitting off .py[co] from .py into separate sub-packages would make sense. It has already been noted that one can drop the .py if you keep the .py[co] and this would leave choice. I guess for dependences you'd then have $foo-py: Provides: $foo $foo-pyc: Provides: $foo $bar: Requires: $foo so installing either -py or -pyc resolves the dependence. We have to somehow prefer one or the other to make our dependence solver happy I guess, not sure if it supports a systemwide "pattern" like "Prefer: *-py" ;) Richard.
Later, Robert
-- Richard Biener <rguenther@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org