On 4/16/2013 18:17, Thomas Klausner wrote:
I disagree -- it is intended to be pro-user, but since we do not provide (enough) binary packages, you only see the downside. The point of the revbumps is that, if you had an abundance of binary packages for your platform, you as a user could install a binary package that suits the packages you already have installed. For example, say png upgrades from 1.5 to 1.6 and its shlib major changes, and the repository has binary packages from before AND after. First, without the revbump, this wouldn't even be possible, since foo-1.0 would EITHER be for png-1.5 OR for png-1.6, but due to the revbump, foo-1.0 is clearly for png-1.5, while foo-1.0nb1 is for png-1.6. So if we had lots of binary packages and smart tools, "pkgtool install foo" would give you a foo package that would work independent of if you already had png-1.6 or still had png-1.5. I see that we're not there yet, but I don't think the method is incorrect, just the lack of binary packages (and perhaps the tools are not good enough).
Yeah, I see want you are saying but...1) I really have been focusing on the source build scenario and not binary packages. These revbumps absolutely make building from source in place unbearable. If functionality was added to pkgsrc that would do "make replace" automatically instead of "make install" when a package was already on the system, this would basically address my complaint. I don't even think it would be that hard to technically do.
So I just want to cd to a directory and type "make install". I don't care if it has to rebuild and replace 20 dependencies first as I don't have to individually "make replace" all 20 individually. Surely you know what I'm talking about?
2) Is the png 1.5/1.6 example actually feasible? with a major api change, all the packages that depend on png would have to be replaced. In any case, I made a specific exception for api changes as the necessity is clear. I am just not sure that all the revbumps fit this use case.
John