Arch Linux

7739 readers

1 users here now

The beloved lightweight distro

founded 4 years ago

MODERATORS

[email protected]

How did the Wine package manage to shave off half its size? (lemmy.one)

submitted 5 months ago by [email protected] to c/[email protected]

4 comments fedilink hide all child comments

Not complaining, just wondering - I was upgrading my system and noticed that the net upgrade size is -748 MB, with just a few important-looking packages set to be upgraded. So I checked and it's wine - going from 1338 MB (9.9-1) to just 587 MB (9.9-2).

I checked the commits to the package repo, and as far as I can tell, this is the only change between 9.9-1 and 9.9-2 - it removes a bunch of hardening flags and that's it. I know these often come at the price of increasing the final build size, but more than double?

For context, the Arch-wide flags are defined here, if I understand it correctly

top 4 comments

sorted by: hot top controversial new old

[–] [email protected] 37 points 5 months ago (1 children)

If you look at the sizes, it used to be that small and something happened with 9.0 that made it twice as big: https://archive.archlinux.org/packages/w/wine/

That version also happens to mess with compilation flags.

Also 8.21 which got big because of https://gitlab.archlinux.org/archlinux/packaging/packages/wine/-/commit/5e370541ce2aaf2b99afd41a9e4d1fe4e163d1da

Compiler flags and not stripping debug symbols again.

It's probably debug symbols and may be a regression unless they've been moved to debuginfod.

[–] [email protected] 8 points 5 months ago

Ah, thank you, I didn't realize there is a package archive I could check for size history

[–] [email protected] 9 points 5 months ago (1 children)

You should still have the previous package in your cache right? If so, extract that and the current package, and then compare the two folders to see what's changed - meld is a good tool for that.

[–] [email protected] 4 points 5 months ago

I'm satisfied with the explanation from the other answer, but thanks, this is a good idea and I hope I'll remember it the next time I want to quickly compare package versions