| 1 |
On Sun, Feb 10, 2013 at 6:48 AM, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> |
| 3 |
> +1. If you can't manage moving/updating your packages properly |
| 4 |
> and on-time from the sci overlay, please get rid of it. |
| 5 |
|
| 6 |
Seems like the alternative solution is to just not have these ebuilds |
| 7 |
in the main tree. |
| 8 |
|
| 9 |
There is nothing wrong with having an overlay that provides a better |
| 10 |
experience than the main tree. Most distros actually operate this way |
| 11 |
- just look up your average non-core piece of FOSS software and the |
| 12 |
first thing their Ubuntu install instructions will tell you to do is |
| 13 |
to add some repository to your list. |
| 14 |
|
| 15 |
I think the main tree can potentially provide a better experience |
| 16 |
since it actually gets checked when dependencies are changed. |
| 17 |
However, that is only true if somebody is maintaining it. |
| 18 |
|
| 19 |
Pillaging the overlays is fine as long as somebody actually maintains |
| 20 |
the package, and it isn't just a one-time copy that resets the clock. |
| 21 |
Otherwise, purpose-driven overlays just make sense - they allow a |
| 22 |
different set of contributors who are more familiar/interested in a |
| 23 |
set of packages to maintain them. |
| 24 |
|
| 25 |
Rich |
Archives