1 |
On Tue, May 22, 2012 at 9:57 AM, Aaron W. Swenson <titanofold@g.o> wrote: |
2 |
> I don't understand how this would be painful. In my mind: |
3 |
> |
4 |
> $ cp ~/github/collab/cat/pkgfile.ebuild ~/gentoo/gentoo-x86/cat/pkg/ |
5 |
> $ cd ~/github/collab/cat/pkg |
6 |
> $ # Follow normal commit steps here. |
7 |
|
8 |
Then realize that you just committed an ebuild that lacks some fix the |
9 |
foo.eclass team quietly made to the previous ebuild when making some |
10 |
tree-wide tweak. |
11 |
|
12 |
In maintaining the mythtv ebuilds one of the things I've noticed is |
13 |
that it is not always easy to keep tree ebuilds in sync with an |
14 |
external overlay, because people do stuff to the tree all the time |
15 |
without involving the maintainers. Usually these are relatively small |
16 |
changes that are good from a quality perspective (often related to |
17 |
dependencies/etc), or just stuff like package moves/virtuals/etc, but |
18 |
the bottom line is that if you just merge some change from an overlay |
19 |
without doing some checks you can end up with a regression. |
20 |
|
21 |
So, if people are going to submit patches to help out it is best that |
22 |
those patches be against what is actually in portage and not some |
23 |
slowly diverging repository. The only way to really address this is |
24 |
to somehow apply changes automatically back into the overlay, but that |
25 |
has issues as well. |
26 |
|
27 |
In a git-based world with easy branching/etc this would likely be less |
28 |
of a problem... |
29 |
|
30 |
Rich |