mpv-plugin/open-in-mpv: new package, add 2.4.0

[vitaly-zdanevich]

Replacement for 17ce941#diff-de89c63c4a2f61950d8337a8c2be1939190e122bba9dd4cad2c5a53a7f2814afL9

[vitaly-zdanevich]

@pastalian please review

[pastalian]

I don't really have any comments on this ebuild. You should get approval from guru-trusted, which I'm not a part of.

[stkw0]

Could we have a non -bin ebuild? It seems doable

[vitaly-zdanevich]

Ok, but it is also good to have -bin as a backup, and for simplicity - so user can install it without Go compiler. I will create source-based ebuild after merging of this one - do not want to mess with git branches.

[stkw0]

About "backups", that's why we usually left at least one older version, so if a new version is broken one can switch to the older one.
As for simplicity, -bin packages complicates things. It's harder to have consistency across the system, it's harder to unbundle libraries, it's more complicated to get security updates if it builds with static libraries.

Only when a package is arguably difficult to build from source (eg: electron programs) or there is some other justification (eg: very big build times as with libreoffice) it's reasonable to have a -bin version. I don't find any good reasons to have a binary ebuild for this, so I am not merging it.

[vitaly-zdanevich]

But why Gentoo added binary mirror for all packages? https://www.gentoo.org/news/2023/12/29/Gentoo-binary.html

To speed up working with slow hardware and for overall convenience

[stkw0]

As you quote it, for slow hardware and programs that take a lot to compile. Because adding a duplicated -bin ebuilds is a very poor solution, and because portage had supported binhosts for a lot of years. Traditionally, if you wanted binaries, you created your own custom binhost. Now Gentoo is kind enough to provide and maintain an official binhost for people who might want it.

Another important point is that portage will detect if the USE flags are different or there is some change between the binhost and your computer in which case it will fall back to compile the program instead of graving the binary. This keeps the coherency of your system, which is much harder to do when one installs pre-compiled binaries without any kind of checking of how those binaries were built.

If you want binaries for arbitrary packages, create your own binhost with whatever is convenient for you. See https://wiki.gentoo.org/wiki/Binary_package_guide

[vitaly-zdanevich]

ok, asked upstream about vendoring Baldomo/open-in-mpv#37

[stkw0]

As it says in the wiki, you can also upload the tarball to Github and create a tag for each release.

[MrRoy]

@vitaly-zdanevich the procedure to package the dependencies is documented here: https://wiki.gentoo.org/wiki/Writing_go_Ebuilds#Packaging_the_dependencies
You can host them on a GitHub or GitLab repository at not cost to you.

It is the packager's job to package dependencies for Gentoo, not upstream. If you will not do it, then please close this PR.

[vitaly-zdanevich]

Upstream is ready, now it my turn... Baldomo/open-in-mpv@803f94c