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
