Andreas Gustafsson <gson%gson.org@localhost> writes: > Greg Troxel wrote: >> > When I try to update a package with "make update", more often than not >> > it fails, complaining that one of the dependencies of the package has >> > a different version already installed. For example, I just tried to >> > do a "make update" in /usr/pkgsrc/databases/pgadmin3, and got: >> > >> > => Full dependency postgresql84-client>=8.4.8: NOT found >> > => Verifying package-install for ../../databases/postgresql84-client >> > => Bootstrap dependency digest>=20010302: found digest-20080510 >> > ===> Checking for vulnerabilities in postgresql84-client-8.4.8 >> > ===> Install binary package of postgresql84-client-8.4.8 >> > pkg_add: A different version of postgresql84-client-8.4.8 is already >> > installed: postgresql84-client-8.4.2nb1 >> > pkg_add: 1 package addition failed >> > *** Error code 1 >> > >> > What am I doing wrong? >> >> Basically, if you don't update everything to consistent versions (from >> the same time in pkgsrc), I think you're going to have trouble. > > What do you mean by "everything" - every installed package, or just > those having a dependency relationship (directly or indirectly) with > the one I'm trying to update? I don't see how unrelated packages > could cause the problem I'm seeing, and with regards to related > packages, isn't updating those to consistent versions exactly what > "make update" is supposed to do? Only those with a (possibly indirect) dependency relationship. But my view as to what's likely to be ok is stronger - I try to have all binary packages matching the current state of pkgsrc source bits on my system, because then the above weaker rule will hold for all packages. > The only method of updating packages I see mentioned in the pkgsrc > guide is "make update"; if you are not supposed to use that, the guide > needs to be updated. If we don't have a working method of updating a > package (or all of them) that users can find in the guide, that's a > pretty sad state of affairs. True. >> In your case, postgresql84-client was updated in pkgsrc but your system >> wasn't updated, and there's a dependency on a specific version for some >> reason. I am not clear on whether this is a bug in make update (that it >> didn't update postgresql84-client) > > "make update" did _try_ to update postgresql84-client - it was > successfully built and packaged as a binary package, but then failed > to install because a different version was already installed. This > does seem like a bug in "make update" to me. I think you're right. But I long ago decided that make update caused me more problems than make replace, so I stopped using it. >> In your case, you could go into databases/postgresql84-client and 'make >> replace', but I don't know how that left your 'make update'. > > I'm reluctant to use "make replace" since the documentation says > "there are no guarantees that dependent packages will still work" when > you do that. Going into databases/postgresql84-client, doing a "make That's true, but read the pkg_rolling-replace man page. When that finishes successfully, all is consistent. > update" there, and resuming the original "make update" did work, but > if you are updating a package like graphics/png, you end up having to > perform this work-around many times. The point of pkg_rolling-replace is to replace each package in topological sort order by dependencies. That may not be what you want, but I suggest reading about it.
Attachment:
pgpDn9Tc2QTGU.pgp
Description: PGP signature