oh eradicator reminded me of something i forgot, versioned eclasses, i know it came up in past, but this really should simply happen, guess now im done :)



Daniel Goller wrote:
I think any change to things pertaingin to gcc, glibc, binuntils and their eclasses should require a rev-bump, even if the change seems trivial like splitting out more functions into eclasses.

It might be rather easy for a developer to revert to an older version of a file, but if version X-Y-rZ is replaced with a incorrectly working ebuild of the same revision level, a user who caught this via a emerge --sync is pretty much "effed" if the breakage is big.

such a rev bump could propate though package.mask into ~arch after devs tested it, then hit ~arch and arch as usual

i know policy says not to bump if it adds no new functionality and we wouldnt want people to remerge OpenOffice for a bug fix someone receives.

Rearranging the ebuilds of essential core funtionality on the other hand i think is different, the inconvenice of down the road merging one that does nothing new for you is far less than finding your system dead after remerging just to add say USE=fortran
You go emerge gcc -vp after adding fortran to USE in make.conf and see portage with the R you hoped for noe U you might be wary of and remerge your gcc, just to find your compiler dead afterwards

now, did somehting like this rcently happen, no thankfully not

did something happen, yes, it is minor, wont break your gcc, only doubles your merge times so people who are used to 1 hour, merge it in 2 hours on x86 at the moment (gcc-3.4.3-r1)

i think this is the right opportunity to say, hey, let's all be careful and make changes to toolchain known to users in a very obvious way

dont make them check ChangeLog each time they merge, aside split out functions into eclass might not alert them anyway

Package.masked would give us time to catch a real problem before it hits ~arch users

or more interestingly arch users if a change might seem to work for both arch and ~arch and is done in one wash

if we dont make changes transparent to users on every package, fundamental tools should be bumped.

Please don;t tell me such a trivial change in how we handle bumps requires a glep ;)

I think this would be a good thing for everyone and we would be safe from "what? nothing changed in foo-X.Y-rZ" in the future

Daniel

Attachment: signature.asc
Description: OpenPGP digital signature



Reply via email to