[gentoo-user] sqlite downgraded by update breaks things

[Grant Edwards]

I just did my usual update

sudo emerge --sync
sudo emerage -auvND world

I noticed that it was downgrading sqlite from 3.43 to 3.42. OK, we'll
assume that portage and the devs know what they're doing...

Now this happens:

$ svn status
svn: E200029: Couldn't perform atomic initialization
svn: E200030: SQLite compiled for 3.43.0, but running with 3.42.0

Have I done something wrong? Is an ebuild broken?

Manually re-merging svn didn't fix it.

Now what do I do?

[Michael]

Post by Grant Edwards
I just did my usual update
sudo emerge --sync
sudo emerage -auvND world
I noticed that it was downgrading sqlite from 3.43 to 3.42. OK, we'll
assume that portage and the devs know what they're doing...
$ svn status
svn: E200029: Couldn't perform atomic initialization
svn: E200030: SQLite compiled for 3.43.0, but running with 3.42.0
Have I done something wrong? Is an ebuild broken?
Manually re-merging svn didn't fix it.
Now what do I do?

The message indicates subversion needs reinstalling with the downgraded sqlite
- potentially @preserved-rebuild ought to catch this, or revdep-rebuild.

You could have a go rebuilding sqlite with +static-libs, but I'm clutching at
straws here. :-/

[Grant Edwards]

Post by Michael
The message indicates subversion needs reinstalling with the downgraded sqlite

I used to run revdep-rebuild after every update, but a few years ago I
thought I read that was no longer a useful thing to do.

I did not try @preserved-rebuild since there was no message from
portage indicating it was needed. Isn't there usually a message from
portage if that set is non-empty? I don't think it would have done
anything, since the library file's version didn't change and
subversion was indeed using the newer library. @preserved-rebuild only
kicks in if the library file version changes and portage keeps the old
version of the file around to keep some apps running until they are
re-built to use the newer version of the library file.

Post by Michael
You could have a go rebuilding sqlite with +static-libs, but I'm clutching at
straws here. :-/

Emerging 'subversion' did it. When I typed 'emerge svn' and something
got merged without any errors I didn't even look to see exactly what
-- though after I emerged subversion I did remember that emerging svn
didn't take nearly as long as it should have.

IMO it's a mistake to have one package called "svn" and another one
called "subversion".

--
Grant

[Jack]

Post by Grant Edwards

Post by Michael
The message indicates subversion needs reinstalling with the downgraded sqlite

I used to run revdep-rebuild after every update, but a few years ago I
thought I read that was no longer a useful thing to do.
portage indicating it was needed. Isn't there usually a message from
portage if that set is non-empty? I don't think it would have done
anything, since the library file's version didn't change and
kicks in if the library file version changes and portage keeps the old
version of the file around to keep some apps running until they are
re-built to use the newer version of the library file.

Post by Michael
You could have a go rebuilding sqlite with +static-libs, but I'm clutching at
straws here. :-/

Emerging 'subversion' did it. When I typed 'emerge svn' and something
got merged without any errors I didn't even look to see exactly what
-- though after I emerged subversion I did remember that emerging svn
didn't take nearly as long as it should have.
IMO it's a mistake to have one package called "svn" and another one
called "subversion".
--
Grant

I'd also consider it a possible bug that subversion didn't require a
rebuild after a version change of one of it's dependencies.  I don't
remember why the downgrade was needed (I got hit by that also) but
perhaps it was added to the tree as stable and then reverted to testing,
but not soon enough?

Jack

[Alan McKinnon]

Post by Grant Edwards
IMO it's a mistake to have one package called "svn" and another one
called "subversion".

Not really. ebuilds tend to be named the same as the project, so apache is
called apache (project name), not httpd (binary name)

The user package is named after what the system user will be, and SVN has
run as "svn" since forever.
Makes total sense, as long as you know exactly what how the software works
and how it's deployed.
Except when it kicks you in the teeth, like what happened here.

OSes are like biology: apparently logical but actually messy

[Matt Connell]

Post by Alan McKinnon
OSes are like biology: apparently logical but actually messy

And both developed organically!

[Grant Edwards]

Post by Alan McKinnon
Not really. ebuilds tend to be named the same as the project, so
apache is called apache (project name), not httpd (binary name)
The user package is named after what the system user will be, and
SVN has run as "svn" since forever. Makes total sense, as long as
you know exactly what how the software works and how it's deployed.

Exactly. :)

[Neil Bothwick]

Post by Grant Edwards
IMO it's a mistake to have one package called "svn" and another one
called "subversion".

The names -f the acct-{user,group} packages follow the actual user names.
So the issue is caused by subversion running as the svn user, portage is
just following upstream.

That does make it any less prone to confusion, but I doubt you will
persuade the subversion devs to change their choice of user name :-O

[Michael]

Post by Grant Edwards
sudo emerge --sync
sudo emerage -auvND world
[...]
$ svn status
svn: E200029: Couldn't perform atomic initialization
svn: E200030: SQLite compiled for 3.43.0, but running with 3.42.0
[...]
Manually re-merging svn didn't fix it.

Doh! Emerging "svn" is basically a nop: all it deals with is account
stuff. Emerging "subversion" fixed it.
Is there a portage mechanism that should have done that?
Why is the account stuff "svn" and the package itself "subversion"?
--
Grant

Our messages crossed. Did you run @preserved-rebuild by any chance?

[Grant Edwards]

Post by Grant Edwards
sudo emerge --sync
sudo emerage -auvND world
[...]
$ svn status
svn: E200029: Couldn't perform atomic initialization
svn: E200030: SQLite compiled for 3.43.0, but running with 3.42.0
[...]
Manually re-merging svn didn't fix it.

Doh! Emerging "svn" is basically a nop: all it deals with is account
stuff. Emerging "subversion" fixed it.

Is there a portage mechanism that should have done that?

Why is the account stuff "svn" and the package itself "subversion"?

--
Grant