Bug 149719

Summary: package should be renamed to python-sqlite
Product: [Fedora] Fedora Reporter: Seth Vidal <skvidal>
Component: python-sqlite3Assignee: Jeff Johnson <jbj>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: bugs.michael
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-03-09 22:03:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Seth Vidal 2005-02-25 18:39:29 UTC
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
python-sqlite

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

Comment 1 Jeff Johnson 2005-03-03 15:38:24 UTC
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 15:40:36 UTC
I agree, renaming them both would be best.



Comment 3 Jeff Johnson 2005-03-03 17:38:18 UTC
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 17:39:32 UTC
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 17:57:33 UTC
'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 17:59:11 UTC
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 22:42:02 UTC
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 23:03:28 UTC
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
sqlite3.

so naming it  sqlite is not only KISS it's also looking at existing
practice.


Comment 9 Jeff Johnson 2005-03-03 23:16:56 UTC
I looked, what I saw was sqlite3, for distros that provide
both.

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 22:03:00 UTC
FIxed in sqlite-3.1.2-1.

Comment 11 Michael Schwendt 2005-03-12 15:05:42 UTC
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'.