1 |
On Thu, 6 Nov 2008 22:51:20 -0800 |
2 |
Donnie Berkholz <dberkholz@g.o> wrote: |
3 |
|
4 |
> > What's the motivation behind this? I can think of several reasons |
5 |
> > why a package maintainer would need to touch a stable ebuild. |
6 |
> |
7 |
> Could you provide a few examples? It's impossible for anyone else to |
8 |
> come up with solutions to problems that haven't been described. |
9 |
> |
10 |
> Once it's stable, it should be static. If they need to make changes, |
11 |
> they should make them in a new revision & stabilize it. That may |
12 |
> require a slight change in our workflow to reduce stabilization |
13 |
> periods in these cases. But I think it's a superior approach to an |
14 |
> ever-changing single revision, as long as portage handles revisions |
15 |
> of filenames instead of revisions of git. |
16 |
|
17 |
Well, if we could get rid of the 30 day wait to get anything done in |
18 |
stable-land then, yeah, that makes a lot of sense. Pretty much all the |
19 |
examples I have in mind hinge on that. Nothing aggravates me more |
20 |
than having a broken package in stable and having to wait a month to |
21 |
fix it. |
22 |
|
23 |
What about things that don't require a revbump though, like build |
24 |
fixes? If the stable version of a package doesn't build with GCC 4.3, |
25 |
and the current unstable can't go stable any time soon (say it breaks |
26 |
ABI or is generally crap), then I have two choices. I can do an |
27 |
unstable revbump consisting of the stable version + a backported patch, |
28 |
or I can just backport the patch directly to the stable version. I |
29 |
currently do the latter, not just because I don't have the time and |
30 |
patience to track these packages for 30 days, file the stabilization |
31 |
bugs, try to get vapier to stabilize s390 and m86k, discover vapier |
32 |
stabilized them a month ago and didn't tell anyone, and generally |
33 |
follow them through to the end -- I did exactly this for GCC 4.1 and it |
34 |
took _over a year_ to sort out -- but also because I don't believe in |
35 |
forcing a rebuild on people for no good reason. |
36 |
|
37 |
If a stable package has an ewarn at the end telling the user they must |
38 |
run "mypackage-updater", and that util is later renamed, do we really |
39 |
need to do a revbump? What about homepage moves? What about stable |
40 |
ebuilds that have a dependency on a package that is then moved to |
41 |
another category? Or USE flag renames? I don't think any of these |
42 |
things should require a rebuild. |
43 |
|
44 |
On the other hand, I see where you're coming from. If changes were |
45 |
made to the process, namely doing away with the arbitrary time limit for |
46 |
trivial changes, then I think I could agree. |
47 |
|
48 |
One other thing I was thinking of - would package maintainers still |
49 |
have write access to the stable tree? If not, who cleans out old |
50 |
ebuilds? |
51 |
|
52 |
|
53 |
-- |
54 |
gcc-porting, by design, by neglect |
55 |
treecleaner, for a fact or just for effect |
56 |
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |