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