what i often find when doing emerge sync is: ebuilds that were stable before have been altered and need to be downloaded again. (e.g. xfree ebuild changed because of new patches to it) so reinstalling xfree would result in a different (more bugfree) version. because i can't remember everything that i have installed or check the changelog for all ebuilds that have changed nor do i think anyone else does this: * wouldn't it be better to do a revision for every change in any ebuild except for unmasking on different processor platforms? the way it is now only emerge -e world periodically would really give me a uptodate system... but this is mainly a waste of processor time. feel free to see forum: http://forums.gentoo.org/viewtopic.php?p=584256 Reproducible: Always Steps to Reproduce:
the current policy is this: if a change fixes compile time bugs, dont bump revision if a change affects the installed package, bump revision everything in between is up to the developer to deem whether a package should get a revision bump or not if you have a specific issue with a package then file a bug against that package
*** Bug 49935 has been marked as a duplicate of this bug. ***
i don't understand it! a compile fix (=diffrend result of the emerge) does NOT get a revision bump? this means that two systems with the same version number and revision number do not have the same executables (worse case scenario). i have as well first started to post on the gentoo forum about this topic: http://forums.gentoo.org/viewtopic.php?t=168779&highlight= it does not go into my mind, why rc init scripts are "compile time bugs"? cheers SteveB
steveb, thanks for brining this issue back up. It's something that has annoyed many people before you and certainly will continue to annoy more in the future if the policy isn't changed. A revision number is a label of a -A REVISION- of something .. by definition. With the current policy Gentoo is changing the semantics and significance of a revision number. Any change at all should lead to a new revision number - doing otherwise would be fooling and misleading masses of people that do not know or care about "Gentoo's way" of thinking about this. I think this issue is closely connected with another. It seems to me that some ebuild-developers are "afraid" of version bumping because they know their little spelling fix or other minor change is going to cost lots of people cpu cycles when they update to the new ebuild revision. I think the solution to the current nightmare is twofold. One, change the "official policy" so that EVERY CHANGE to an ebuild, big or small, results in a new ebuild revision. Along with this should be an easy to read changelog which could be displayed showing what changes have been done from the currently installed revision (reading the full dev changelog isn't interesting when all you want are good stable ebuilds). Two, introduce a new feature in portage which lets you filter updates better as to avoid the current situation where every little revision change will have you compile the full program again. Now, I'm all for compiling my own programs, it just gets a bit silly when you have to compile -r1 through -r15 of the same program, gaining what looks to you as .. "nothing" ..
This is a massively devisive issue which I still believe my solution is the best one for. That said, I don't know if anyone has heard it yet, so here goes. Add CVS header support to portage! And there you go. Voila! All of a sudden, all of our worst fears are vaped. If revision 1.3 and 1.4 of a certain 3.4.0-r6 ebuild (for example, in this case gcc) differ by a fix for a spelling mistake, then portage should allow you to update your installation without too much effort. It might make a difference, and you shouldn't have to make the effort to write your own ebuild comparison script (ecatmur has one, revcheck.sh, search the forums) simply in order to ensure that your package was merged with the latest revision of the current revision of the ebuild (see the paradox?). The other alternative, of course, is to change the revision number policy. If we had -r1, -r2, -r3 etc. for major updates (changes to the package and so on and so forth) and -r1.0, -r1.1, -r1.2,... , -r2.0, -r2.1, -r2.2, ... , -r3.0, ... for minor bumps, then that would remove the need for portage to parse CVS headers. Either way, the current situation is something of a farce. Look at the difference between the original x11-base/xorg-x11-6.7.0 ebuild and the current one and your jaw will hit the flaw. There's very little consistent between the two. Each minor change itself didn't deserve a revision bump under the current rules, but the fact that what's there now and what was there in the first place differ almost entirely mean that this system DOES NOT WORK. Sadly. :-( I would be interested to hear the thoughts of others with regards these two propositions. I think I know a man who could add support for this to portage within a few days if there's support...
