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.

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:

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.

And finally here's an example how to introduce new packages to tree
without upstream releases:

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.

Some history and initiative: bug #713802

-- juippis

Reply via email to