[Bug 1192457] ZSTD compressed kernel module files are 35% bigger
https://bugzilla.suse.com/show_bug.cgi?id=1192457 https://bugzilla.suse.com/show_bug.cgi?id=1192457#c20 --- Comment #20 from Michal Suchanek <msuchanek@suse.com> --- (In reply to Dominique Leuenberger from comment #17)
(In reply to Martin Wilck from comment #16)
Let me ask again how we are supposed to proceed now.
The tests we discussed continues in home:dimstar:Live - when we overcome the obstacle, we can move to zstd again and build TW using this.
Thanks for setting this up. The build with Factory packages showed the CD size as 630MB which is less than 650MB but maybe it's supposed to be in different units.
Everyone understands that if unsurmountable problems occur, the project fails. But what happened here is that we pulled back on the first occurence of an issue. The side effect of this is that real-world testing effectively doesn't happen any more. So possible other issues will not be found, and the known ones will be harder to solve.
It was not 'pulled back' - but moved to the 'devel area' instead of the product. OBS is powerful enough to let us work out kinks outside of the actual product build as long as we need to. And only put it inside the product when we feel ready for it.
Then you probably want to link Kernel:HEAD rather than Kernel:stable
It was expected that some issues would occur. It was known beforehand that package size would increase.
So why did nobody look at the product deliverables and verify that they can be produced? Throw over the fence and let Release Managers pick up the broken glass is not the way to go.
And how do we look at them and ensure that they are buildable? That's what we have release managers for. To know the deliverables. I was not aware that there is a medium built that has exactly CD size. All the media I work with are either way over 4G or 100-300MB so I do not see the problem there.
Therefore if we want to have this feature, we need to deal with that and free the required space on the media.
Be my guest: branch it, fix it, submit it.
That's not so easy. Last time I tried to branch a release package it would not build because it requires some complex project setup which is not documented. When I did some project setup it would not build presumably because there is some size quota on the home projects. -- You are receiving this mail because: You are the assignee for the bug.
participants (1)
-
bugzilla_noreply@suse.com