Mailing List Archive

On 2023-09-06, Grant Edwards <grant.b.edwards@gmail.com> wrote:

> 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

On Wednesday, 6 September 2023 17:09:15 BST Grant Edwards wrote:
> 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?

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. :-/

On Wednesday, 6 September 2023 17:21:14 BST Grant Edwards wrote:
> On 2023-09-06, Grant Edwards <grant.b.edwards@gmail.com> wrote:
> > 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?

On 2023-09-06, Michael <confabulate@kintzios.com> wrote:

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

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.

> 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

On 9/6/23 12:42, Grant Edwards wrote:
> On 2023-09-06, Michael <confabulate@kintzios.com> wrote:
>
>> The message indicates subversion needs reinstalling with the downgraded sqlite
>> - potentially @preserved-rebuild ought to catch this, or revdep-rebuild.
> 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.
>
>> 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

On Wed, Sep 6, 2023 at 6:43?PM Grant Edwards <grant.b.edwards@gmail.com>
wrote:

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

--
Alan McKinnon
alan dot mckinnon at gmail dot com

On Wed, 2023-09-06 at 19:05 +0200, Alan McKinnon wrote:
> OSes are like biology: apparently logical but actually messy

And both developed organically!

On 2023-09-06, Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> 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. :)

On Wed, 6 Sep 2023 16:42:20 -0000 (UTC), Grant Edwards wrote:

> 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


--
Neil Bothwick

The Japanese call us lazy, but at least we cook our fish!