22 Mar
2024
22 Mar
'24
3:19 a.m.
Hi, I just saw that the major version number was recently bumped on the
osmocom rtl-sdr.
Unfortunately this seems to be causing upgrade problems because if a user
updates the drivers to the new major version number (eg to get Blog V4
support), the soname is now different, and this means that all previously
installed software that uses librtlsdr will need to be recompiled from
scratch, and software from the package manager will simply be broken.
I'm not sure if the recent changes warrant a major version change and the
problems that come with it?
Regards,
Carl
22 Mar
22 Mar
5:05 a.m.
To add to this here is a Twitter/X thread that the developer of SDR++ has
put out, regarding the issues he's seeing with this major version number
change.
https://twitter.com/ryzerth/status/1771016439681466697
Regards,
Carl
On Fri, Mar 22, 2024 at 3:19 PM Carl Laufer <admin(a)rtl-sdr.com> wrote:
Hi, I just saw that the major version number was
recently bumped on the
osmocom rtl-sdr.
Unfortunately this seems to be causing upgrade problems because if a user
updates the drivers to the new major version number (eg to get Blog V4
support), the soname is now different, and this means that all previously
installed software that uses librtlsdr will need to be recompiled from
scratch, and software from the package manager will simply be broken.
I'm not sure if the recent changes warrant a major version change and the
problems that come with it?
Regards,
Carl
26 Mar
26 Mar
9:13 p.m.
Hi,
the reason why the version was bumped is because there are several
forks of rtl-sdr that used version 0.8 and beyond, without changing the
library name. Many people requested the release of a new version, and to
avoid colissions of the version number with those forks, the major
version was bumped to 2 as a 'leap forward'.
On 22.03.24 05:05, Carl Laufer wrote:
To add to this here is a Twitter/X thread that the
developer of SDR++
has put out, regarding the issues he's seeing with this major version
number change.
https://twitter.com/ryzerth/status/1771016439681466697
<https://twitter.com/ryzerth/status/1771016439681466697>
Interestingly the last reply in that thread is from someone who
maintains one of those forks of rtl-sdr, and the first thing he did was
change the version to 2.1 - so yeah, in the end it was useless.
We could probably revert the SOVERSION to 0, however, for those
distributions that already picked up the change this would be pretty
weird.
Regards,
Steve
27 Mar
27 Mar
1:11 a.m.
Hi Steve,
If the upstream osmocom soversion is bumped, then all forks will eventually
need to follow too. Because software packages will begin getting written
for version 2, then those forks will need to update to be useful to those
programs.
I believe the soversion should only be bumped when there have been breaking
non-backwards compatible API changes made. Nothing of that sort has
happened with the recent pushes.
So IMO I think reverting the soversion to 0 is the best solution, and that
should be pushed ASAP before the problem becomes more widespread. I just
talked to the dev of SDR++ and he agrees with this solution too. The
distro's that already picked it up probably should be notified that the
soversion was bumped by mistake and that it's been reverted.
Regards,
Carl Laufer
On Wed, Mar 27, 2024 at 9:15 AM Steve Markgraf <steve(a)steve-m.de> wrote:
Hi,
the reason why the version was bumped is because there are several
forks of rtl-sdr that used version 0.8 and beyond, without changing the
library name. Many people requested the release of a new version, and to
avoid colissions of the version number with those forks, the major
version was bumped to 2 as a 'leap forward'.
On 22.03.24 05:05, Carl Laufer wrote:
To add to this here is a Twitter/X thread that
the developer of SDR++
has put out, regarding the issues he's seeing with this major version
number change.
https://twitter.com/ryzerth/status/1771016439681466697
<https://twitter.com/ryzerth/status/1771016439681466697>
Interestingly the last reply in that thread is from someone who
maintains one of those forks of rtl-sdr, and the first thing he did was
change the version to 2.1 - so yeah, in the end it was useless.
We could probably revert the SOVERSION to 0, however, for those
distributions that already picked up the change this would be pretty
weird.
Regards,
Steve
9:12 a.m.
Hi guys,
FYI If the 2.x version of the package is installed, it will not be automatically replaced
by version 0.x, even if 0.x is newer and 2.x is older. The APT package manager adheres to
the semantic versioning scheme to identify the newer version.
Best Regards,
Andrey
On 27 Mar 2024, at 00:11, Carl Laufer
<admin(a)rtl-sdr.com> wrote:
Hi Steve,
If the upstream osmocom soversion is bumped, then all forks will eventually need to
follow too. Because software packages will begin getting written for version 2, then those
forks will need to update to be useful to those programs.
I believe the soversion should only be bumped when there have been breaking non-backwards
compatible API changes made. Nothing of that sort has happened with the recent pushes.
So IMO I think reverting the soversion to 0 is the best solution, and that should be
pushed ASAP before the problem becomes more widespread. I just talked to the dev of SDR++
and he agrees with this solution too. The distro's that already picked it up probably
should be notified that the soversion was bumped by mistake and that it's been
reverted.
Regards,
Carl Laufer
On Wed, Mar 27, 2024 at 9:15 AM Steve Markgraf <steve(a)steve-m.de
<mailto:steve@steve-m.de>> wrote:
> Hi,
>
> the reason why the version was bumped is because there are several
> forks of rtl-sdr that used version 0.8 and beyond, without changing the
> library name. Many people requested the release of a new version, and to
> avoid colissions of the version number with those forks, the major
> version was bumped to 2 as a 'leap forward'.
>
> On 22.03.24 05:05, Carl Laufer wrote:
> > To add to this here is a Twitter/X thread that the developer of SDR++
> > has put out, regarding the issues he's seeing with this major version
> > number change.
> >
> > https://twitter.com/ryzerth/status/1771016439681466697
> > <https://twitter.com/ryzerth/status/1771016439681466697>
>
>
> Interestingly the last reply in that thread is from someone who
> maintains one of those forks of rtl-sdr, and the first thing he did was
> change the version to 2.1 - so yeah, in the end it was useless.
>
> We could probably revert the SOVERSION to 0, however, for those
> distributions that already picked up the change this would be pretty
> weird.
>
> Regards,
> Steve
>
1:12 p.m.
Carl Laufer <admin(a)rtl-sdr.com> writes:
If the upstream osmocom soversion is bumped, then all
forks will eventually
need to follow too. Because software packages will begin getting written
for version 2, then those forks will need to update to be useful to those
programs.
I think the real issue is what are forks doing and why.
There are basically two kinds:
[things that aren't forks that github wrongly labels forks, which are
just personal copies, either to have the bits, or as staging areas for
proposing changes]
a fork that intends to be compatible with a few features that are not
yet in the main repo, or that have been rejected. here, the release
versions and soversion should track more or less exactly
a fork that rejects the original repo, is renamed, and is its own
thing
Then there are mirrors on different forges, often because some people
don't like other's forges (e.g., because github is proprietary, or
because !github is perceived as leaving out the used-to-monopoly crowd).
Often (not about this situation), I find that forks do not clearly state
that they are a fork, what the plan is and why, and what the status is.
I have found this community to be particularly hard to understand in
terms of fork status, relative to most others.
Overall, a healthy ecosystem
So: for each fork, why does it exist, and is there a plan to fold it in?
38
days inactive
43
days old
5 comments
4 participants
participants (4)
-
Carl Laufer -
Greg Troxel -
Steve Markgraf -
Андрей Родионов