Red Hat Bugzilla – Bug 149719
package should be renamed to python-sqlite
Last modified: 2007-11-30 17:11:00 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 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.
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.
I agree, renaming them both would be best.
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 ;-)
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?
'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 ...
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.
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.
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.
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 ...
FIxed in sqlite-3.1.2-1.
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'.