| 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 |
Archives