Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[james]

On 06/14/2016 01:48 AM, Daniel Campbell wrote:
> On 06/13/2016 11:24 PM, Alexander Berntsen wrote:
>> In addition to what Peter Stuge (correctly) identifies as needing to
>> change, there also needs to be a modularisation of Gentoo-curated
>> package repositories.
>>
> What sort of modularization are you talking about? Would we suggest
> something like GNOME, KDE, XFCE, Mate, Cinnamon, et al getting their own
> overlays? dev-lang/foo getting its own overlay, etc?
>
> To some degree, that will simplify some people's trees and quicken
> emerge, but then it just pushes maintainance to a part that most users
> don't really mess with much (repos.conf)
>
> You can achieve mostly the same end via your own git repo at /usr/local/
> and pulling overlays in via either layman or git submodules, for
> overlays that aren't already in layman.
>
> zugaina and layman are great tools that could use a bit more polish, and
> could be either adopted or assisted as an official part of the handbook.
>
> The issue here is similar to the issue Ubuntu and Debian face with PPAs.
> There's no guarantee on their quality, and if an overlay becomes popular
> then there may be pressure put on the Gentoo tree to adopt whatever the
> popular overlay has. This could be detrimental *or* beneficial,
> depending on what the changes are.
>
> tldr modularization sounds good on paper but I don't see it being
> beneficial in the long run. I would be happy with the requirements to
> get into layman being somewhat relaxed and/or halfway automated so users
> can host anywhere they want, get listed in layman as "not vetted" but
> still available, and then some sort of process or mechanism to go from
> "unvetted" to "vetted", and if they're lucky, "official". It would
> require less shuffling of resources, as well.
>

For starters, we had a thread recently on gentoo user about if there is 
a similar tool as portageq to identify a non-dev and the related 
packages they support. Listing by repo is all there is and it is scant. 
So maybe metadata.xml or overlays and such is a good start? What if a 
non-dev is primary to more that one repo? His own,  a group of friends 
and one at work? I'd suggest expanding this to folks with the proxy 
designation for now, and work out how these tools should work, before 
attempting to spread tools to a myriad of outside (no G-QA) ebuilds, 
regardless of where they are housed. CoreOS has many ebuilds too and 
it's only a matter of discovery before those CoreOS ebuilds start to 
become interesting to the gentoo communities. Ebuilds are becoming 
universally popular. Other distro folks, who can read and follow basic 
shell, can and do often use them as a roadmap to installing software.

In fact there are few tools to list packages outside the tree by 
category, scope, venue, maintainer etc etc. I'd speculate that the 
development of those tools, specific to itemization and characterization 
of ebuilds outside of the formal portage tree,
are what's really most needed (along with robust documentation). Along 
with a universal metadata.xml  effort. Universal metadata.xml  for all 
ebuilds that included  checksums/hashes/keys/etc could allow for 
packaged up download files (tar_balls, zipped, compresses etc) to be 
identified and characterized and could be auto interrogated with 
extensions to wget, git, ftp and a host of other protocols employed to 
download source files.

James