IMHO, the -r number of every changed ebuild should be bumped since it's the only way to tell the users about the modification... For example, the xfree ebuild has included some up-to-date versions of the SiS graphics driver and if didn't try to re-emerge it just for fun I wouldn't even know! This is bad since I choosed Gentoo to be on the bleeding edge... :-( Only sky is the limit when increasing these numbers so I don't get the reason why maintainers are so affraid to do so... I think it should be in the "maintainer's policy" (if something like that exists)... Thanks... Radek
If it doesn't affect a significant portion of users, in most cases it is not bumped. Another example would be a patch for CJK (chinese, japanese, korean) support, again not affecting a significant portion of users. The point is saving the majority of users what's essentially a USELESS compilation so that the minority can benefit from a fix.
Yeah, but real change from program XYZ version 1.2.3.4 to 1.2.3.5 can be a typo correction in the source and still it's bumped... :-) How do I know something has changed, then? Should I watch the ChangeLogs every day? That's impossible. I think it would be better to bump the number and let user decide whether the change is important enough for him (using the --changelog argument). Seems much better to me then the opposite way (users searching the changelogs for changes manually)... I think most Gentoo users are the advanced ones and they would be happy if such decision (about the importance of a modification) is left up to them rather than the developers... :-) Radek
For "advanced" users, they can create a script that checks the installed version of the ebuild with the one in portage and update when there is a difference. It is up to the developer to decided if an ebuild will get a -r bump or not since they are arguably the most qualified to make that decision. Marking this bug as INVALID.
Do you have time to write that script? I don't... :-( Bumping the number is a zero-time operation... Recompiling? Isn't that what Gentoo is all about?
please, the script can't be that hard, your installed ebuilds are in /var/db/pkg, and the new ebuilds are in /usr/portage, run diffs, and report to yourself. while you're recompiling xfree for the next (useless to you) nvidia driver update, I'm sure you can tweak such a script.
:-) While I still can't see what's so bad about "useless" recompilation (I run emerge niced on the background, you don't?) I have to stick with what you think it's correct... :-) Can't you at least issue a feature request for portage, please? Something like "emerge -u --any-change world"... I really think this kind of feature should be made kind of official or else the maintainers are doing useless work (if users can't benefit from it since they even don't know)... :-( Radek P.S.: I have the nvidia card on the other machine... :-)
ok, let the portage team look at your request
Thank you... Radek
*** This bug has been marked as a duplicate of 38671 ***
Are you sure about the duplicity? Radek
I'm not sure about the dupe either. Actually, the reporter has a point. Every change in an ebuild that results in a different output should be revision bumped. I know this may be a lot of rev bumps for some packs, but this is our way to test stuff. As ~arch user you sort of volunteer to do this more frequent recompilation. The concern of users rebuilding too much should only be a concern in the stable tree. It is a different thing if something is actively being worked on in p.mask, it can stay at the same revision then.
Thanks for the support, I was about to feel a bit odd with my opinions... :-) Radek
I still think it's a dupe as revision bumps without a feature to ignore them (as requested in the other bug) will result in unhappy users who wonder why they have to recompile stuff so often. While the motivations are opposite the requested feature is basically the same. But if people disagree I'll leave this open.
Please, take a look at the other bug again (#38671), I can't find anything but some new file. No complaints or stuff... :-( Radek
ups, sorry. Misread the bug number it seems. *** This bug has been marked as a duplicate of 38674 ***
I don't think this is a duplicate of bug 38674, as they are very different requests. Bugzilla provides a "depends on" and "blocks" feature for the kind of relationship that this bug and bug 38674 have.
I agree, something like "depend" would be far better than "duplicate". These are really two different requests... Should I reopen the bug again? :-) Anyway, the ideas from bug 38674 are good as long as you ensure that the maintainers will bump the "less significant part" on every (even pathetic) change... This way, you can close both bugs... :-) Radek
its not a dupe
Portage won't be doing this check any time soon. It's excessive and adds in code depenencies and complexity which isn't useful for most cases. I'm closing it. Someone can take the bug if they wish.
