Red Hat Bugzilla – Bug 487978
Review Request: sqlitebrowser - Design and edit database files compatible with SQLite
Last modified: 2014-07-15 04:18:06 EDT
Spec URL: http://ispbrasil.com.br/sqlitebrowser/sqlitebrowser.spec
SRPM URL: http://ispbrasil.com.br/sqlitebrowser/sqlitebrowser-1.3-1.fc11.src.rpm
SQLite Database Browser is a freeware, public domain, open source
visual tool used to create, design and edit database files compatible
with SQLite. It is meant to be used for users and developers that want
to create databases, edit and search data using a familiar
spreadsheet-like interface, without the need to learn complicated
SQL commands. Controls and wizards are available for users to:
* Create and compact database files
* Create, define, modify and delete tables
* Create, define and delete indexes
* Browse, edit, add and delete records
* Search records
* Import and export records as text
* Import and export tables from/to CSV files
* Import and export databases from/to SQL dump files
* Issue SQL queries and inspect the results
* Examine a log of all SQL commands issued by the application
koji scratch build dist-f11
I have concerns about this package building its own private copy of sqlite from source and then linking it statically. Any problems that are found in sqlite will need to be fixed twice: once in sqlite and again in this package. Better would be to convince the sqlite maintainer to provide a -static package for this package to use; best would be to get this package to link dynamically against the existing Fedora sqlite package.
just a few notes ...
I just tried the .spec on RHEL-5:
* I had to change BuildRequires qt3-devel to qt-devel
* I had to include /usr/lib64/qt-3.3/bin in path to be able to use qmake
* I had to set QTDIR="/usr/lib64/qt-3.3"
otherwise the build went fine, and I can use sqlitebrowser without any problems (on x86_64, for the record)
note that in project svn, there were some efforts to port this to Qt4, so personally, I'd throw this version away and try to encourage the author to release the new version including the possibility of dynamic linking
It's been 3.5 months since my comment and over a months since Karel's and there's been no response. Did you still want to submit this package? Please respond soon or I'll go ahead and close this ticket.
No response; closing.
I had a look at this ... Updated to the latest version, and it seemed easy to patch it to use the system sqlite-devel package. I'll attach/upload the updated spec-file and the patch.
Created attachment 462091 [details]
Created attachment 462092 [details]
Patch to make sqlitebrowser use the system sqlite library
Created attachment 462102 [details]
Patch to fix the text in the About dialogbox
sqlitebrowser would claim to be built with version 3.6.18 of the sqlite library, because of a hardcoded text. Changed the text to use the SQLITE_VERSION macro, so it reports the version of sqlite-devel it was actually built with.
Created attachment 462734 [details]
Had a closer look at the Fedora packaging guidelines etc. and think this is a prettier (more correct) spec-file, with (for instance) version numbering according to Fedora guidelines. Also included an icon in the package, for use with the desktop-file, the menu looks prettier now :-)
Looks like I'm volunteering to maintain this package ? I'm new at that, anyone want to be my guide ? :-)
Anyway, since the top hit in Google for "sqlitebrowser rpm" is this Bugzilla entry, it makes sense to me to report my findings here.
(In reply to comment #9)
> Looks like I'm volunteering to maintain this package ? I'm new at that, anyone
> want to be my guide ? :-)
if you volunteer to take this, please follow the wiki:
and open a new review request
(feel free to put me into CC)
(In reply to comment #10)
> if you volunteer to take this, please follow the wiki:
I had looked at that page earlier ... I find I still have some questions that I'd like to ask before committing to the job, like:
* What kind of hardware should I have ?
* How many resources are required on the machine(s) (RAM, disk) ?
* What are the requirements on the Fedora install(s) ?
(So far, I have tended to skip every other release, lazy, probably.
But that probably won't do, as a Fedora developer ? )
* Excluding the work done on the actual packages (which probably varies
wildly), how much free time (per week ? day ??) must one have to keep up
with things ?
The wiki-page you mention doesn't answer all these (stupid) questions.
(In reply to comment #11)
> * What kind of hardware should I have ?
any that runs Fedora :-) ... well, in theory, you should test on all architectures supported by the package, in practice it is enough to use one
> * How many resources are required on the machine(s) (RAM, disk) ?
there are no such requirements - it is nice if you have enough resources to compile packages you maintain (i.e. you need disk space for the development packages), but you can workaround by using scratch build feature in koji
> * What are the requirements on the Fedora install(s) ?
> (So far, I have tended to skip every other release, lazy, probably.
> But that probably won't do, as a Fedora developer ? )
it is not that important what are you running, but it is nice if you "dogfood" i.e. use the recent version of the package (on a recent system) yourself
you can also install different release in a virtual machine ...
> * Excluding the work done on the actual packages (which probably varies
> wildly), how much free time (per week ? day ??) must one have to keep up
> with things ?
hard to tell, depends on your level of involvement ... you are not obliged to follow all the news and what is cooking, it is sufficient to keep eye on the announcements (which is low volume, a few messages per week), and there is not much to act on - transition of development resources from cvs to git or similar things don't happen every day
don't be afraid, just try that, and if you find it too much, you can always give up
*** This bug has been marked as a duplicate of bug 1119644 ***