Neither this GLEP nor GLEP 74 state what to do with fetchable files of ebuilds with PROPERTIES="live" set, so both portage and pkgcore add DIST entries to Manifest. This is not how it should be because: a) It breaks packages of careless maintainers Example: https://gitweb.gentoo.org/repo/proj/guru.git/tree/dev-util/rust-analyzer-bin b) It forces not-so-careless maintainers to use wget hacks in src_unpack Example: https://gitweb.gentoo.org/repo/gentoo.git/tree/app-text/jabref-bin/jabref-bin-4.9999.ebuild I suggest to require package managers ignore SRC_URI of live ebuilds while generating a manifest, which should be trivial. The only problem is, there would be no way to verify distfiles of 9999-only ebuilds with mixed live/static sources. Other solutions: * Implement IGNORE from GLEP 74 and add downloadable files, which are present in live ebuild(s) *only*, with this tag (needs not-so-trivial changes) * Introduce a new variable (like SRC_LIVE_URI), which would be valid for packages with PROPERTIES="live" only. It's kinda silly and has no backward compatibility. * Write eclass for that wget hack (extra silly) * Introduce SRC_LIVE_URI *and* eapi9-src_live_uri.eclass with that wget hack (unbelievably silly beyond words)
PROPERTIES=live was never intended to affect SRC_URI.
Not a bug in the GLEP, but exactly as designed. Distfiles in SRC_URI are static. Therefore they can be mirrored, and their integrity can be verified by a checksum in the Manifest. If an ebuild doesn't use a static distfile then it should not declare it in SRC_URI. Also, this has nothing to do with PROPERTIES. (In reply to jan Anja from comment #0) > a) It breaks packages of careless maintainers > Example: > https://gitweb.gentoo.org/repo/proj/guru.git/tree/dev-util/rust-analyzer-bin That ebuild should decide if it wants to be a live ebuild, in which case it should use git-r3.eclass. Otherwise, it should use a release tarball with a proper version number. Reassigning.
I'm about to push a versioned ebuild for rust-analyzer-bin and I'll drop the 9999 ebuild, thanks for the feedback. This was a topic I brought up previously in #gentoo-dev-help before publishing the ebuild because I knew it would be sort of cheating the manifest. I was advised that the current way of doing it should be acceptable because in theory you'd have a live package but instead of live sources you have a live tarball. Out of curiousity, what would be the best way to create such a "live binary" ebuild?
(In reply to James K from comment #3) > Out of curiousity, what would be the best way to create such a > "live binary" ebuild? Short answer: Don't. :) Seriously, this is strongly discouraged. If there is a release tarball then the ebuild should be versioned. Longer answer: If you absolutely must, use explicit wget in src_unpack, followed by unpack. Don't specify SRC_URI in that case.
(In reply to Ulrich Müller from comment #4) > (In reply to James K from comment #3) > > Out of curiousity, what would be the best way to create such a > > "live binary" ebuild? > > Short answer: Don't. :) > Seriously, this is strongly discouraged. If there is a release tarball then > the ebuild should be versioned. > > Longer answer: If you absolutely must, use explicit wget in src_unpack, > followed by unpack. Don't specify SRC_URI in that case. Understood, thanks! I'll add a live dev-util/rust-analyzer from source eventually. rust-analyzer-bin will be only versioned releases.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/proj/guru.git/commit/?id=f37e5467e4d5ca888aa29532cd8bd96d1d332a54 commit f37e5467e4d5ca888aa29532cd8bd96d1d332a54 Author: James Kalyan <contrib_x@protonmail.com> AuthorDate: 2021-07-23 03:52:55 +0000 Commit: James Kalyan <contrib_x@protonmail.com> CommitDate: 2021-07-23 03:52:55 +0000 dev-util/rust-analyzer-bin: drop 9999 Closes: https://bugs.gentoo.org/803125 Signed-off-by: James Kalyan <contrib_x@protonmail.com> .../rust-analyzer-bin-9999.ebuild | 22 ---------------------- 1 file changed, 22 deletions(-)
