| 1 |
On Tue, Jun 10, 2014 at 4:57 AM, Thomas Kahle <tomka@g.o> wrote: |
| 2 |
> |
| 3 |
> My personal attitude: It is just not worth the effort to rewrite |
| 4 |
> their build systems for the ~10 users out there. I have better |
| 5 |
> things to do with my time and I think that these packages can |
| 6 |
> live forever in the overlay and that is completely OK this way. |
| 7 |
|
| 8 |
I think this is a fairly common issue, actually. Many ebuilds live |
| 9 |
out in overlays (if they're lucky) or just in bugzilla (if not) simply |
| 10 |
because they have QA issues that nobody wants to deal with. I've seen |
| 11 |
ebuilds in bugzilla that get bumped as regularly as anything in the |
| 12 |
tree. |
| 13 |
|
| 14 |
QA can be a double-edged sword. Sometimes it can turn a good ebuild |
| 15 |
into a great one. At other times it can result in a fair-to-good |
| 16 |
ebuild leaving the tree entirely. |
| 17 |
|
| 18 |
I don't see overlays as a problem though. The main issue I've seen |
| 19 |
with them is when people make changes to the tree that requires |
| 20 |
updating reverse dependencies they don't update overlays, and users |
| 21 |
using overlays can end up being in a broken state for a time. |
| 22 |
Obviously we can never control whether overlays get updated, but we |
| 23 |
could require tree-wide updates like this to get announced, instead of |
| 24 |
just having a tracking bug that only notifies maintainers of impacted |
| 25 |
packages/etc. That would be more noise though, and likely |
| 26 |
bikeshedding that those making the changes want to avoid. Or we can |
| 27 |
just accept that those using overlays will have them break from time |
| 28 |
to time. |
| 29 |
|
| 30 |
Rich |
Archives