Bug 1477740

This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

This is still true as of sqlite-3.20.1-2.fc27.x86_64
Again, currently the package sqlite2 provides the binary /usr/bin/sqlite, while the package sqlite provides the binary /usr/bin/sqlite3.

I suggest renaming the binary and manpage in sqlite2 to sqlite2, and renaming the binary and manpage provided by sqlite to sqlite.

I just found out about this bugreport by reading a mail on the devel list.

If you intend renaming

/usr/bin/sqlite3 -> /usr/bin/sqlite

e.g. as in resolving the irritation with sqlite2 vs sqlite3, then please keep a symlink that points from the renamed sqlite3 to sqlite2 back to sqlite3

e.g

/usr/bin/sqlite
/usr/bin/sqlite3  <--- as symlink to sqlite

otherwise you may end up breaking tons of scripts that have the sqlite3 binary referenced inside.

This would come equal as if you renamed "grep" to "grep2" or "grep3" etc. this will end up breaking tons of scripts and I am not willing to fix all the references, where we deal with the sqlite3 binary...

that should have been: "sqlite3 to sqlite back to sqlite3".

Thinking this further:
It may even cause incompatibilities if you would provide a symlink if e.g. something like this is done in scripts (not tested):

if [ -f "/usr/bin/sqlite3" ] ; then
  echo "found!"
fi

or

if [ -x "/usr/bin/sqlite3" ] ; then
  echo "found!"
fi

What I am up here is this: People can do various things with sqlite in e.g. bash scripts like querying a database and extract values out of it for further processing.

Now you can e.g. have a process somewhere in one script that tests for the existence of the executable binary of sqlite3. If you now rename it to sqlite, then the file can't be found and an error may be sent to the admin.

If you now say: place a symlink that points to sqlite3 from sqlite, then this may also cause scripts to break if the admin doesn't test for the existence of a "file" sqlite3 rather than an "executable" of sqlite3 but bash reports back it's now a symlink and not an executable.

So far for the technicals... Not to mention that such a change may also cause "change reqirements" and "change requests" in case Fedora is used in corporates that also provide documentations and quality books for their customers (e.g. if a firm uses Fedora for whatever reasons and have it installed as service for another customer, who then wants to have a quality approved documentation).

I know this sqlite2 and sqlite3 thing may have been historical grown. But most distros refer as sqlite3 to it (iirc). Breaking this will break not just scripts but also documentation that needs to be hunted and fixed everywhere.

I prefer to see sqlite3 as a new version of sqlite. New versions of any program will have some incompatibilities, but most people just get used to the changes that came with new version of, say, ls, rather than creating separate commands ls2 and ls3.

The point here is that we should discourage gratuitous versioning. Fedora is supposed to lead by using the newest versions of its component packages, by providing smooth upgrade path rather than a versioning labyrinth.

There are of course situations, like the current one with Python 2 vs 3, where we need to have the python2 and python3 versions, because of wide-ranging consequences for other packages. I don't think this is the case here: much fewer packages depend on sqlite. 

I do concede that upstream seems to use sqlite3 instead of treating it as an update to sqlite; I assume because of API and file format incompatibilities. I believe this is a mistake and we should try to contact them about it. Is anyone on this list signed up for the sqlite devel list? I do read the newsgroup feed but I can't post---but if noone else takes this up, I will sign up and post.

(In reply to Przemek Klosowski from comment #6)
> I prefer to see sqlite3 as a new version of sqlite.

That wasn't my point!

My point was not meant to stay with sqlite2. Most people use sqlite3 these days.

My point was, that if you also rename the binary /bin/sqlite3 to /bin/sqlite, that you end up breaking thousands of scripts that people have.

1) You break the scripts, because the binary "sqlite3" can not be referenced anymore.
2) You break the documentations that people have written.

3) If you work in a corporate (like an IT-Consulting company) that uses RHEL, CentOS and Fedora systems in their workflow, that you also end up breaking the stuff they have. And it's not a simple "go fix your scripts" kind of process. These companys have processes to follow. Specially if they created some official documentations for some of their customers and these documentations needs to be altered. E.g. all occourances of "sqlite3" needs to be rewritten to "sqlite" (s/sqlite3/sqlite/g). This requires a change management. The documentation and scripts they made for customers needs to be changed. A change process needs to be established, the documents and scripts needs to be changed another process of quality assurance needs to be implemented and everything reviewed again.

Of course the point 3) here can be a bit confusing. But note that there is also RHEL here that has long term support for their customers. And the stuff needs to work, in case you intend updating the packages for RHEL as well. So changing names will break the stuff.

> New versions of any program will have some incompatibilities, but most people
> just get used to the changes that came with new version of, say, ls, rather
> than creating separate commands ls2 and ls3.

Yes! If you speak about the normal users of Linux and Fedora then this may be right. Speaking in corporate language then this ends up breaking things. Nobody wants that.

But if you can encourage upstream sqlite developers to have the final binary drop the "3" at the end, then it's fine. This means that on the long run every distribution and other operating systems (like Windows or macOS etc.) will adopt the filename change.

Again: I am speaking about the binary executable! Not the naming convention of the package or something.

But this is just my own opinion. I am not subscribed to the devel list (and usually want to stay out of the conversation there) but this one caught my attention. So please understand my concerns...

This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.