1 |
On Mon, Nov 2, 2020 at 9:13 PM Joonas Niilola <juippis@g.o> wrote: |
2 |
|
3 |
> Hey, |
4 |
> |
5 |
> I'm suggesting a new QA policy to disallow any "live-ebuild-only |
6 |
> packages" being hosted in ::gentoo. Rationale being the same as why |
7 |
> -9999 packages can't have KEYWORDS: They are unpredictable and |
8 |
> potentially insecure. Unpredictability could mean upstream repo being |
9 |
> broken at any given time placing users in an awkward situation, where |
10 |
> they are able to build some packages while not the others. Upstream |
11 |
> repo can also be force-pushed over. I feel like packages offered in |
12 |
> ::gentoo shouldn't have these issues, and the need to have at least one |
13 |
> safe release available to users that's guaranteed to build. |
14 |
> |
15 |
|
16 |
I disagree. These packages are not installable by default, and must be |
17 |
unmasked by users, so this tradeoff is one we expect them to make. Are |
18 |
there practical problems that these packages pose to developers? You listed |
19 |
a bunch of user problems, but again users are opting into these problems, |
20 |
presumably. |
21 |
|
22 |
|
23 |
> |
24 |
> With Git-like VCS's becoming popular, it is super easy to create an |
25 |
> unchanged snapshot based on a commit. Even devmanual encourages this |
26 |
> with proper guide how-to: |
27 |
> |
28 |
> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html#snapshots-and-live-ebuilds |
29 |
> (https://devmanual.gentoo.org/keywording/index.html) |
30 |
> |
31 |
> We currently have 43 "live-ebuild-only" packages in tree. Out of those |
32 |
> 19 are totally unbuildable, that's 44 % of all packages present in the |
33 |
> repo. Overall the maintenance of these live-ebuild-only packages looks |
34 |
> low, there's only a handful of ebuilds that have good quality and no |
35 |
> issues at all. 12 of them, 28 %, are still on EAPI-5. Of all 43, only 2 |
36 |
> would require the maintainer to generate a tarball by themself, while |
37 |
> others can utilize upstream's tagged releases, or ability to make a |
38 |
> snapshot from a specific commit. Obviously if this policy passes, I'll |
39 |
> be helping getting these packages keyworded. |
40 |
> |
41 |
|
42 |
But again, why are we making this a firm policy; as opposed to letting the |
43 |
maintainer make their decision? |
44 |
|
45 |
|
46 |
> |
47 |
> And finally here's an example how to introduce new packages to tree |
48 |
> without upstream releases: |
49 |
> |
50 |
> https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-libs/rlottie?id=42873c46b7ed07d5b4f8af5fcf08d8549cb6385b |
51 |
> |
52 |
> https://gitweb.gentoo.org/repo/gentoo.git/commit/media-libs/rlottie?id=2de52234783be909f6e4aed333533e6a804e8e6b |
53 |
> |
54 |
> https://gitweb.gentoo.org/repo/gentoo.git/commit/media-libs/rlottie?id=8305f0c6cd0ce8cb5ac0f2d92569acce36a5cc0a |
55 |
> etc... |
56 |
> |
57 |
> https://gitweb.gentoo.org/repo/gentoo.git/commit/media-libs/rlottie?id=24c48b325dd5a22284d077d6581a1a45e397e511 |
58 |
> |
59 |
> If the only available version for a package doesn't build - or can't be |
60 |
> guaranteed to build - then it should be last-rited, or not exist in |
61 |
> ::gentoo repo at all. |
62 |
> |
63 |
|
64 |
We can't guarantee any package to build..so I'm not sure how this is a |
65 |
practical policy goal. |
66 |
|
67 |
-A |
68 |
|
69 |
|
70 |
> |
71 |
> Some history and initiative: bug #713802 |
72 |
> |
73 |
> -- juippis |
74 |
> |
75 |
> |