On 4/16/2013 20:19, Greg Troxel wrote:
John Marino<netbsd%marino.st@localhost> writes:Honestly I think the "make replace" issue is the main one. If that were fixed, I could live with dependence rebuilds. It's just time (unless I don't have much, then it's still annoying.)What specific 'make replace' issue do you mean? The biggest problem as I see it is that when files move from one package to another there is no way to replace packages individually. As for installing one package, pkgsrc expects a consistent checkout of src, and a set of installed packages that are consistent with that. So the rule is first do pkg_rr (or similar) and then you can build things. If you don't like that you should be using the stable branch.
So you see that the scenario I've been talking about violates the premise. For example, In January I build a bunch of packages from the master branch. Six months later, in July, I pull the latest source on the master branch and try to "make install" some package. Now pkgsrc tries to rebuild a bunch of packages that are already installed and each one fails at "make install" because the package is already installed. It basically has no way of detecting the package is already installed and replacing it. It just fails, and about 20 more upstream will fail too. I either have to "make replace" each failure or use the "rolling replace" tool.
Now, you may say I'm misusing pkgsrc, and I never should have pulled from the master branch again. Or that I should have rebuilt everything in a chroot root and used a package manager to replace all the outdated packages. I don't think my use case is crazy though.
Now, it would be a feature to do something where one can essentially do pkg_rr projected onto the dependencies of a single package, plus any rebuilds that are required from that. But I'm not sure that's really a good idea because it accomodates more inconsistency than pkgsrc usually has.
To iterate, I think of a lot of the frustration that people that people from source (constantly updated trunk branch) experience with pkgsrc could be mitigated if it just didn't break on "make install". I guess functionally this is what "rolling replace" is doing but that tool never seems to work without incident. I am suggested if "make install" were a bit smarter, the RR tool could be eliminated completely.