Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf

[Rich Freeman]

On Sun, Feb 10, 2013 at 7:51 AM, Alexander Berntsen
<alexander@××××××.net> wrote:
>
> On 10/02/13 13:11, Rich Freeman wrote:
>> - just look up your average non-core piece of FOSS software and the
>>  first thing their Ubuntu install instructions will tell you to do
>> is to add some repository to your list.
> And the second search result is the Ubuntu troubleshooting broken
> installs as a result of adding other repositories.
>
> I accept that there may exist reasons for using overlays. "Ubuntu do
> it!" is not one.

I have mixed feelings on this.  I'd never advocate doing anything
simply because everybody else is doing it - if I wanted to use Ubuntu
I'd be using Ubuntu.

There are pros/cons to overlays right now:
Pros include:
1.  More flexible maintenance model.  The overlay maintainer can
choose who has access to it.  They don't have to worry about people
making tree-wide commits without knowing what they're doing, because
any damage is contained to the overlay (though obviously any package
in an overlay could mess with anything on a user's system).

2.  More flexible QA model.  Usually that means less QA, which has its
own pros and cons, but it /could/ actually mean more QA, or just
different QA.  Right now we have no way of communicating to users
(beyond masks) that packages vary in quality level, and overlays could
be a way to accomplish this.  You could also have a set of related
overlays that provide a dev/test/stable experience.

Cons include:
1.  No relationship to the tree.  If somebody messes with one of your
dependencies they will not take any care not to break your package.

2.  Non-mainstream experience.  Because Gentoo tends to be
overlay-averse, most users don't use them at all.

3.  No real organization.  Beyond an entry in the layman list there
really isn't any systematic tracking of overlays and their
quality/etc.  We don't "grade" overlays or anything like that.

#1 is the biggest con I'd say.  It is made worse by the fact that we
don't have a main repository QA cycle (I'm not suggesting we have
one).  For something like Ubuntu anybody maintaining a 3rd party
repository can monitor the release cycle and test against the new
dependency versions before they are released and be ready on day one.
For Gentoo you would have to pay very close attention to bugzilla,
lists, irc, and perhaps even mail aliases (not open to the public) to
have any idea that some change is about to happen to one of your
dependencies if you aren't in the main tree.

A fix for #1 might be some way to allow external parties to register
interest in upcoming changes and get alerted.  Then those changing
libs could just trigger the alerts (and that system might also file
bugs against in-tree packages to request testing).  We obviously
wouldn't consider any outside overlays blockers, but we could be nicer
to them.  Of course, that takes work and I'm skeptical that this would
ever happen.

So, those are just my thoughts on overlays.  I don't think they're a
bad thing.  However, there are some things about Gentoo that make them
less practical than on other distros.  I won't argue that you get the
best possible experience if the package is in the tree AND IT IS
MAINTAINED.  The problem is that in a volunteer-based organization the
second half of that is hard to guarantee.

Rich