Bug 487978
Summary: | Review Request: sqlitebrowser - Design and edit database files compatible with SQLite | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Itamar Reis Peixoto <itamar> | ||||||||||
Component: | Package Review | Assignee: | Nobody's working on this, feel free to take it <nobody> | ||||||||||
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
Severity: | medium | Docs Contact: | |||||||||||
Priority: | medium | ||||||||||||
Version: | rawhide | CC: | fedora-package-review, i, kvolny, linuxcub, notting, pahan | ||||||||||
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: | 2009-07-05 17:12: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: | |||||||||||||
Attachments: |
|
Description
Itamar Reis Peixoto
2009-03-01 22:57:29 UTC
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]
Updated spec-file
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]
Updated spec-file
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: http://fedoraproject.org/wiki/Join_the_package_collection_maintainers 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: > http://fedoraproject.org/wiki/Join_the_package_collection_maintainers 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 *** |