Bug 149719 - package should be renamed to python-sqlite
package should be renamed to python-sqlite
Product: Fedora
Classification: Fedora
Component: python-sqlite3 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Depends On:
  Show dependency treegraph
Reported: 2005-02-25 13:39 EST by Seth Vidal
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-09 17:03:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Seth Vidal 2005-02-25 13:39:29 EST
Description of problem:
There are several python-sqlite packages existent in the world. Most of them are
just the bindings and they link to a version of sqlite.
In fedora extras the sqlite version is 2.8.X and the bindings are called

when sqlite is updated it the python bindings  are too and so naming the python
bindings python-sqlite3 is just confusing.

moreover there is a separate set of python bindings for sqlite, written by Matt
Wilson, that are named pysqlite3.

So that's even more confusing.

If we rename it now it will keep from causing other problems b/t test releases
Comment 1 Jeff Johnson 2005-03-03 10:38:24 EST
Sure, changing pkg names can be done.

Howvere, I think that python-foo and foo both should have
the same name. Whether foo = "sqlite" or foo == "sqlite3"
is the question for both sqlite* and python-sqlite* packages.
Comment 2 Seth Vidal 2005-03-03 10:40:36 EST
I agree, renaming them both would be best.

Comment 3 Jeff Johnson 2005-03-03 12:38:18 EST
So sqlite or sqlite3? I went with "sqlite3" because that
is what seemed wisest (just before sqlite-3.1.2 release)
at the time, "sqlite3" seemed the least surprising call.

Opinions welcomed ;-)
Comment 4 Seth Vidal 2005-03-03 12:39:32 EST
changing them both to sqlite, from sqlite3 seems to be the best approach.

we're not shipping older versions of sqlite in the distro - why append
the major version number to the package name?
Comment 5 Jeff Johnson 2005-03-03 12:57:33 EST
'k, "sqlite" is KISS is reasonable. OTOH, attempting to conform with
existing practice universally is usually wise, rather than NIH
dsitro-centric consideration.

Will do, I like KISS ...
Comment 6 Seth Vidal 2005-03-03 12:59:11 EST
if you want to conform to other's standards - then just follow the
packaging of sqlite 2.8.* in fedora extras, fedora us and freshrpms.

which is just to name the package its name, not including the major
version number.
Comment 7 Jeff Johnson 2005-03-03 17:42:02 EST
Heh, it's not as simple as following fedora.us guidelines,
nor do I need an example of how to build packages.

The change s/sqlite3/sqlite/ will happen my next build, sqlite-tcl
subpkg same time.
Comment 8 Seth Vidal 2005-03-03 18:03:28 EST
I wasn't recommending either. You said:

"OTOH, attempting to conform with
existing practice universally is usually wise, rather than NIH
dsitro-centric consideration."

I was siting 3 other places that are NIH that are using sqlite and not

so naming it  sqlite is not only KISS it's also looking at existing
Comment 9 Jeff Johnson 2005-03-03 18:16:56 EST
I looked, what I saw was sqlite3, for distros that provide

Since the API is incompatible, the issue was discussed with
various people involved with FC packages, including sopwith
and misa.

Pre-existing FE, nee fedora.us, packaging was examined, which
was already named sqlite, before choosing sqlite3
as a name. Because the upgrade issues were unclear, it was decided
(not just by me) that "sqlite3" was the more conservative, and less
likely to be disruptive to pre-existing packaging, approach.

Due diligence was done, and your bug report will be satisifed
as stated.

Happy? Hind-sight is easy ...
Comment 10 Jeff Johnson 2005-03-09 17:03:00 EST
FIxed in sqlite-3.1.2-1.
Comment 11 Michael Schwendt 2005-03-12 10:05:42 EST
Actually, comment 4 is misguided. The major difference between sqlite 2.x and
sqlite 3.x is a different SONAME. The versions are neither ABI compatible nor
API compatible. The sqlite 3.x SONAME is 'sqlite3' not 'sqlite'.

Note You need to log in before you can comment on or make changes to this bug.