pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: make update failing with "a different version ... is already installed"

Andreas Gustafsson <> 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.


>> 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

Home | Main Index | Thread Index | Old Index