On Mon, Nov 2, 2020 at 9:13 PM Joonas Niilola <juip...@gentoo.org> wrote:
> Hey, > > I'm suggesting a new QA policy to disallow any "live-ebuild-only > packages" being hosted in ::gentoo. Rationale being the same as why > -9999 packages can't have KEYWORDS: They are unpredictable and > potentially insecure. Unpredictability could mean upstream repo being > broken at any given time placing users in an awkward situation, where > they are able to build some packages while not the others. Upstream > repo can also be force-pushed over. I feel like packages offered in > ::gentoo shouldn't have these issues, and the need to have at least one > safe release available to users that's guaranteed to build. > I disagree. These packages are not installable by default, and must be unmasked by users, so this tradeoff is one we expect them to make. Are there practical problems that these packages pose to developers? You listed a bunch of user problems, but again users are opting into these problems, presumably. > > With Git-like VCS's becoming popular, it is super easy to create an > unchanged snapshot based on a commit. Even devmanual encourages this > with proper guide how-to: > > https://devmanual.gentoo.org/ebuild-writing/file-format/index.html#snapshots-and-live-ebuilds > (https://devmanual.gentoo.org/keywording/index.html) > > We currently have 43 "live-ebuild-only" packages in tree. Out of those > 19 are totally unbuildable, that's 44 % of all packages present in the > repo. Overall the maintenance of these live-ebuild-only packages looks > low, there's only a handful of ebuilds that have good quality and no > issues at all. 12 of them, 28 %, are still on EAPI-5. Of all 43, only 2 > would require the maintainer to generate a tarball by themself, while > others can utilize upstream's tagged releases, or ability to make a > snapshot from a specific commit. Obviously if this policy passes, I'll > be helping getting these packages keyworded. > But again, why are we making this a firm policy; as opposed to letting the maintainer make their decision? > > And finally here's an example how to introduce new packages to tree > without upstream releases: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-libs/rlottie?id=42873c46b7ed07d5b4f8af5fcf08d8549cb6385b > > https://gitweb.gentoo.org/repo/gentoo.git/commit/media-libs/rlottie?id=2de52234783be909f6e4aed333533e6a804e8e6b > > https://gitweb.gentoo.org/repo/gentoo.git/commit/media-libs/rlottie?id=8305f0c6cd0ce8cb5ac0f2d92569acce36a5cc0a > etc... > > https://gitweb.gentoo.org/repo/gentoo.git/commit/media-libs/rlottie?id=24c48b325dd5a22284d077d6581a1a45e397e511 > > If the only available version for a package doesn't build - or can't be > guaranteed to build - then it should be last-rited, or not exist in > ::gentoo repo at all. > We can't guarantee any package to build..so I'm not sure how this is a practical policy goal. -A > > Some history and initiative: bug #713802 > > -- juippis > >
