Re: [Trustedqsl-testing] TQSL 2.6 beta release

[Greg T. <gd...@le...>]

Rick Murphy <k1...@ar...> writes:

> On Fri, Feb 18, 2022 at 1:52 PM Greg Troxel <gd...@le...> wrote:
>
>> Rick Murphy <k1m...@gm...> writes:
>>
>>   The only patch I'm carrying is to force bdb instead of lmdb, because I
>>   believe there is some lack of automatic upgrade for users, and that
>>   seems more serious than whatever benefit switching brings.  But I may
>>   be confused on this point.
>
> That's effectively a one-time loss and is a really tough thing to fix, with
> a simple work-around.
>
> If you previously ran TQSL with BerkeleyDB, and now have an updated build
> with LMDB, then doing an upgrade within TQSL means that you need to build
> both into the package at least once. Then you can use the BDB code to dump
> the database and write a new one with LMDB.  I prefer LMDB due to licensing
> reasons.
>
> If you just ignore this, which is what I've been doing, then when you
> update from BDB to LMDB, the only loss is that the record of previously
> uploaded QSOs is lost. It'll rebuild as you upload, or, more likely, it'll
> get rebuilt when you restore a backup file.  That's the migration: build a
> tqslbackup.tbk on the BDB version, upgrade to LMDB, then restore the .tbk
> file. Since TQSL automatically backs this up (and keeps a history of 10
> backups), the data is always there for restoration.
>
> Finally, if you do nothing, then you get one re-upload of a QSO before it
> gets recorded in the new database; Logbook will reject any duplicates.
>
> Given that set of circumstances, database upgrades are hard and it's easier
> to just upgrade.

So given that, and that there are fairly few users, I should just switch
to lmdb and there will be a bunch of re-uploads, but no real harm done.
I think you explained before; sorry for not putting that in the makefile
and asking again.

> My plan for a future TQSL release is to look for a backup file that can be
> used to restore the upload data whenever the database can't be opened, and
> restore that. At that point I'm going to remove support for BerkeleyDB and
> go with only LMDB.

I don't see any reason for me to wait to switch pkgsrc, unless you want
to tell me I shouldn't.

>>   I have set a lot of cmake args about RPATH, which gets me a working
>>   package, apparently in a previous go-round when I switched to cmake,
>>   but the details have left my head.  I have not tried to see which of
>>   them are really necessary.  (I think RPATH should be set automtically
>>   for prefixes which are not in the system's default search path.)  But
>>   until I determine what's really going on, don't take this as a bug
>>   report, just a comment.
>>
>
> I am a complete novice about RPATH.  I've had strong feedback that it
> should never be set, but if I don't set the path then TQSL doesn't work
> because it cannot find libtqsllib.so.

(Assuming an all-ELF world and ignoring Windows for the RPATH discussion.)

The statements that it should *never* be set are just wrong and it's
unreasonable of people to make them.

There are are variety of operating systems, and a variety of packaging
systems.  GNU/Linux distributions are a combination of OS and packaging.
For each scheme, there are norms about what should be done with RPATH,
and those norms are different on different systems.  The right thing to
do is to follow the norms for the system on which tsql is being built.
Some systems are anti-RPATH and that's their call for those systems.
But a claim from that world that everyone else is wrong and should never
use RPATH is unreasonable and unhelpful.

My impression is that on almost all systems, the standard approach is:

  1) When libraries are in /usr/lib or someplace else in the
  system-configured default path, there is no need to add RPATH
  arguments to the link line, and thus they should be omitted.
  /usr/local/lib might or might not be in this category on any
  particular system.  /usr/lib64, if it exists, is almost certainly in
  this category.

  2) When an executable links with a library that is not in the default
  search path, such as /usr/pkg/lib, /usr/myhamstuff/lib, or any other
  user-chosen path, then it's necessary to pass e.g. -R/usr/pkg/lib or
  -rpath /usr/pkg/lib to the linker.

  2a) Some systems might say that in case 2, you still shouldn't use
  rpath and instead you should do something else.  I don't know that
  this case actually exists, and I don't understand how it could work in
  the general case.

On systems like Debian, all packages are built with prefix=/usr, and
thus there should be no -R.  On systems like pkgsrc, with /usr/pkg or
/opt/pkg, which are not part of the default path, -R should be used.

A question for people that think "rpath should never be set": Assume
that on a system like Debian I build tqsl from source and configure it
to be in prefix=/usr/foo so that my build will be separate from the
system-provided and system-controlled packages in /usr.   So I have

  /usr/foo/lib/libtqsllib.so 
  /usr/foo/bin/tqsl

Am I supposed to use -R in this build?  If not, how does
/usr/foo/bin/tqsl find the matching libtqsllib.so?

I really don't know who you are hearing from that there should never be
RPATH set, and what their argument is that my summary is wrong.  Until a
convincing explanation is provided (here), my recommendation is not to
listen to them.

> The current CMakeLIsts.txt for tqsl defaults to not setting RPATH. You may
> need to use "-DTQSL_RPATH" to enable the path to the shared lib to be
> properly set.

The pkgsrc package currently has:

  # \todo Check/rationalize
  CMAKE_ARGS+=            -DBDB_PREFIX=${PREFIX}
  CMAKE_ARGS+=            -DBDB_INCLUDE_DIR=${PREFIX}/include/db5
  CMAKE_ARGS+=            -DCMAKE_INSTALL_PREFIX=${PREFIX}
  CMAKE_ARGS+=            -DCMAKE_INSTALL_MANDIR:PATH=${PKGMANDIR}
  CMAKE_ARGS+=            -DCMAKE_INSTALL_RPATH=${PREFIX}/lib
  CMAKE_ARGS+=            -DCMAKE_BUILD_WITH_INSTALL_RPATH=TRUE
  CMAKE_ARGS+=            -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=FALSE

and as I understand cmake, CMAKE_INSTALL_RPATH is the normal approach.

I don't know why TQSL_RPATH is needed vs INSTALL_RPATH but it may well
make sense and I'll look into it.

However, there are really multiple separate things going on:

  whether to form the union of rpath args as returned when searching for
  dependency libraries (which might be in different prefixes)

  whether to add rpath for our prefix's lib (because tsql depends on
  libtsqllib.so

  whether to use the rpath args above, or omit them

On non-rpath systems, the pkgconfig etc. files for dependencies
shouldn't have rpath.  And on systems that want rpath, they should.

So logic that says "add to rpath by default if not /usr/lib or
/usr/lib64" should get things right for almost everybody.

> This code doesn't require c++11 but should tolerate a newer C++ compiler.
> There's only two places where the code cares about the c++ version
> (src/location.cpp, in a pair of string trimming functions). Both versions
> of the code are included.

Thanks, I'll look into this more.

>>   There is incorrect use of "test ==" (non-POSIX usage) in
>>   osx_createdmg.sh.  Not a big deal but it trips a portability check and
>>   has to be listed for skipping in the pkgsrc package, and it would just
>>   as well to fix anyway.
>
> Fixed. Doesn't matter for anything but a mac anyway.  I guess this
> shouldn't be "osx_" any longer.

Thanks.

>>   As far as I know, the license isn't OSI or FSF approved.  I wonder if
>>   Debian has decided to accept it, as "DFSG-free as determined by
>>   Debian" is our third approval authority for licenses to avoid
>>   requiring the user to configure them as acceptable.  What I really
>>   mean is: Does Debian put tqsl in "main", "contrib" or "non-free"?
>
> Debian Stretch:
> $ apt-cache -f search trustedqsl | grep File
> Filename: pool/main/t/trustedqsl/trustedqsl_2.2.2-1_amd64.deb
>
> I think "main".

Thanks.  I will see about getting the license promoted within pkgsrc to
being treated as free software.


73 de n1dam