Package Details: meshoptimizer 0.22-1

Git Clone URL: https://aur.archlinux.org/meshoptimizer.git (read-only, click to copy)
Package Base: meshoptimizer
Description: Mesh optimization library that makes meshes smaller and faster to render
Upstream URL: https://github.com/zeux/meshoptimizer
Licenses: MIT
Submitter: mosra
Maintainer: mosra
Last Packager: mosra
Votes: 3
Popularity: 0.000000
First Submitted: 2020-04-18 11:43 (UTC)
Last Updated: 2024-12-05 10:21 (UTC)

Latest Comments

vitaliikuzhdin commented on 2024-12-14 11:18 (UTC) (edited on 2024-12-14 11:23 (UTC) by vitaliikuzhdin)

If you decide not to split the build, that's totally fine. In that case, it might help to add conflicts=('gltfpack') so pacman doesn’t throw an error if someone tries to install both.

My main reason for suggesting the split wasn’t about saving disk space -- it was more about avoiding confusion. The full source build includes everything, but the binary version is named differently and only contains part of the project. Just a heads-up, provides and conflicts aren’t indexed by search, and you can’t use yay -Qo gltfpack for AUR packages since they don’t provide the content list. This is why I suggested the split -- without it, people might have trouble finding the right package. But it's up to you in the end.

mosra commented on 2024-12-11 08:01 (UTC)

Haha, originally this package didn't even contain gltfpack because I didn't have a need for it in magnum-plugins, but later on I thought "ah why not, it's small enough" and added it.

I'm not completely opposing your idea but it's more of a question of user convenience to me. For example libpng contains the pnm2png etc. executables and I don't think anybody really uses those. The main use case is supplying a library to be used by other packages, and the executables are there just because they're small enough and don't add any extra dependency. (As opposed to e.g. Debian-based distros, where each library is unnecessarily split into a billion of tiny & cryptically named packages, and the overhead of dealing with that outweighs any benefits of slightly less disk space used if only a subset is installed.)

And I see it similarly here, (to me at least) gltfpack is just one executable of the meshoptimizer library and since it's a single tiny file that has no other dependency that the library itself, it feels like unnecessary overhead to split it to a dedicated package that the user then has to explicitly install. If it'd be a multi-megabyte executable depending on various image libraries etc. (or if it'd be one of the GUI demos that use GLFW), splitting would make sense to me, but as it is now it doesn't really.

That being said, I can understand people who want to use gltfpack would search for that name and not for meshoptimizer. Would this be improved if I added provides=('gltfpack') to the PKGBUILD?

vitaliikuzhdin commented on 2024-12-10 15:30 (UTC)

Could you consider splitting this package into meshoptimizer and gltfpack? These tools are not necessarily used together, and maintaining a combined package creates confusion, especially since there is only a binary distribution available for gltfpack.

To resolve this, I've uploaded a gltfpack-bin package to the AUR, which provides the prebuilt binary. It would make more sense to have separate source-built packages for meshoptimizer and gltfpack rather than a combined one alongside a binary package that only provides gltfpack.

For an example of a possible split, you can refer to this gist: https://gist.github.com/vitaliikuzhdin/52c9b36124ee97e223dff8ae6ab5e206

This would make usage and maintenance clearer for everyone. Thank you!