Gentoo Archives: gentoo-dev

From: Daniel Campbell <zlg@g.o>
To: gentoo-dev@l.g.o
Subject: Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)
Date: Thu, 16 Jun 2016 07:34:24
Message-Id: 7ee3ac02-1d5d-ad7e-3010-cdbf544f3f8f@gentoo.org
In Reply to: Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project) by Alexander Berntsen
1 On 06/15/2016 12:22 AM, Alexander Berntsen wrote:
2 > On 14/06/16 08:48, Daniel Campbell wrote:
3 >> What sort of modularization are you talking about?
4 > The cheap answer is "as much as possible.
5 >
6 >> Would we suggest something like GNOME, KDE, XFCE, Mate, Cinnamon,
7 >> et al getting their own overlays? dev-lang/foo getting its own
8 >> overlay, etc?
9 > Yes. Although I would not want to impose my thoughts too much in this
10 > regard, as I think we have a lot of capable devs, who are hopefully more
11 > fit for this task than I am.
12 >
13 >> To some degree, that will simplify some people's trees and quicken
14 >> emerge, but then it just pushes maintainance to a part that most
15 >> users don't really mess with much (repos.conf)
16 > I don't know what maintenance you are speaking about.
17
18 There is overhead in choosing which repositories you want to include in
19 your 'upstream'. Even with an automated tool like layman, there's
20 maintenance overhead. We'd need another tool to assist in
21 discoverability, too. Let's say this idea takes off and we start with
22 100-200 user repos. It's meaningless to learn that there are that many
23 repositories and list them (that's what layman currently does). What's
24 important is getting a list of *which packages* those repos have, even
25 if it's one-by-one and cat'd to a file.
26
27 Even if that is written, it adds yet another facet to system administration.
28 >
29 >> You can achieve mostly the same end via your own git repo at
30 >> /usr/local/ and pulling overlays in via either layman or git
31 >> submodules, for overlays that aren't already in layman.
32 > The repository isn't hosted by us along with everybody else's
33 > repository, so there is no community element. And the Gentoo tree isn't
34 > modular today. So I completely fail to see how that would be "mostly the
35 > same".
36 >
37 >> zugaina and layman are great tools that could use a bit more
38 >> polish, and could be either adopted or assisted as an official part
39 >> of the handbook.
40 > That would be great.
41 >
42 >> There's no guarantee on their quality, and if an overlay becomes
43 >> popular then there may be pressure put on the Gentoo tree to adopt
44 >> whatever the popular overlay has. This could be detrimental *or*
45 >> beneficial, depending on what the changes are.
46 > I assume that using PPAs is at your own risk, so this is not a real
47 > problem. Gentoo would have a curated and reviewed set of repositories,
48 > venturing outside of that is clearly for power users.
49 >
50 Okay, and who chooses which ones get curated? Developers? The whole goal
51 of this decentralization, from what I gather, is community. If
52 developers are overseeing it all, it adds overhead to developers and
53 doesn't really foster community control or support.
54
55 If the goal is community then it should be *community curated*, which
56 means it can exist entirely outside of Gentoo's infra and we shouldn't
57 have to care about it. Why do Gentoo devs need to curate it if the aim
58 is community control? In fact, that's already possible right here, right
59 now.
60
61 I'm not against the idea per se, but at the same time I don't see why
62 it's the responsibility of developers to make this sort of thing happen.
63 It's not a trivial thing we can mark off in a checklist. However, there
64 are enough tools in the Gentoo toolbox to make such a thing happen -- if
65 the community wants it. And if they want it, they can build it. We don't
66 do anything, to my knowledge, to stifle the growth of community
67 repositories.
68 --
69 Daniel Campbell - Gentoo Developer
70 OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
71 fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies