Bug 567257
Summary: | Review Request: libfm - GIO-based library for file manager-like programs | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Christoph Wickert <christoph.wickert> |
Component: | Package Review | Assignee: | Mamoru TASAKA <mtasaka> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | fedora-package-review, j, mtasaka, notting, than |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | Flags: | mtasaka:
fedora-review+
|
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | libfm-0.1.9-2.fc13 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-06-01 19:00:53 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
Christoph Wickert
2010-02-22 13:19:25 UTC
Well, my impression is that the name libfm.so is too short to be included in %_libdir. Can the upstream rename this to something like libpcmanfm.so ? It is a generic library for file managers that may very well be used by other projects as well. The name libpcmanfm would be misleading, libfm on the other hand fits quite well (FM = file manager). libfm is under development for more than 8 months now and nobody seemed to have problems with the name. It's already in other distros with that name and we have quite a few 5 letter libs (libaa, libao, libcv, libdv, libdw, libfa, libgc, libgd, libGL, libgs, libmb, libml, libmp, libnl, libpq, libt1, libts, libwv, libXi, libXt to only name some of them). I really don't see a problem with this. Will review, however please wait... Thanks for picking this up. I talked to PCMan yesterday and he said he can't follow your concerns. If someone asked him 6 months ago, he maybe would have renamed the package, but now he is not willing to do it any longer. I guess we have to accept this and follow upstream. Well, * License - is GPLv2+ * BR/Requires - ">= 2.16.0" on "BR: gtk2-devel" is not needed because gtk2-devel in currently supported Fedora branches all satisfy this dependency: https://fedoraproject.org/wiki/Packaging/Guidelines#Explicit_Requires - Would you explain why BR: gvfs-devel or R: gvfs is needed? grep'ing gvfs returns nothing. (if gvfs-devel * %description - Please don't repeat the same description on -gtk (note that -gtk subpackage has R: libfm) * Directory ownership issue - Please make it sure that all directories which are newly created by a package which are to be installed newly are correctly owned by the package - Please address the ownership of the following directories --------------------------------------------------------------------- %{_sysconfdir}/xdg/libfm/ %{_libdir}/libfm/ --------------------------------------------------------------------- * -devel/-gtk-devel file splitting - Well, I will say listing files in %_includedir/%name on -devel and -gtk-devel in the current way is error-prone. Would you list files in %_includedir/%name in some automated way like below? --------------------------------------------------------------------- %install .... .... %find_lang %name echo '%%defattr(-,root,root,-)' > base-header.files echo '%%defattr(-,root,root,-)' > gtk-header.files for f in %buildroot%_includedir/%name/*.h do bf=$(basename $f) for dir in base job do if [ -f src/$dir/$bf ] then echo %_includedir/%name/$bf >> base-header.files fi done for dir in gtk do if [ -f src/$dir/$bf ] then echo %_includedir/%name/$bf >> gtk-header.files fi done done %files .... .... %files devel -f base-header.files %defattr(-,root,root,-) %doc TODO %dir %{_includedir}/libfm/ %{_includedir}/libfm/fm.h %{_libdir}/%{name}.so (for .pc file, see below) %files gtk-devel -f gtk-header.files %defattr(-,root,root,-) %{_includedir}/libfm/fm-gtk.h %{_libdir}/%{name}-gtk.so --------------------------------------------------------------------- * pkgconfig .pc file - libfm.pc.in contains --------------------------------------------------------------------- 8 Requires: gtk+-2.0 >= 2.16.0 gthread-2.0 gio-unix-2.0 10 Libs: -L${libdir} -lfm -lfm-gtk --------------------------------------------------------------------- This should defintely not in -devel subpackage (if you want to split -devel and -gtk-devel subpackage). If you want to split -devel and -gtk-devel subpackage, I would propose - that current libfm.pc.in should be renamed to libfm-gtk.pc.in - libfm.pc.in should newly be created which has proper Requires and Libs and this change may be preferable also to the upstream. ping? The split was done upstream late last night and I haven't had the time to package the new tarballs yet. I will update this bug later today. (In reply to comment #5) > * License > - is GPLv2+ fixed > * BR/Requires > - ">= 2.16.0" on "BR: gtk2-devel" is not needed because gtk2-devel > in currently supported Fedora branches all satisfy this dependency: > https://fedoraproject.org/wiki/Packaging/Guidelines#Explicit_Requires The explicit requires guideline doesn't apply here as I'm not requiring a library. Only the version number could be omitted, if all currently supported Fedora branches fulfilled this requirement, but EPEL does not. > - Would you explain why BR: gvfs-devel or R: gvfs is needed? > grep'ing gvfs returns nothing. You are right, it's a runtime dependency only, not a BR. It's optional, but highly recommended, otherwise things like trash:// or mounting of remote file systems wont work. > * %description > - Please don't repeat the same description on -gtk (note that > -gtk subpackage has R: libfm) Why not? Only the first part of the description is the same, the rest is different for the (sub)packages. IMO the description must be understandable for every single package standalone because nether a package manager nor rpm -i will show you the description of the required packages. > * Directory ownership issue > %{_sysconfdir}/xdg/libfm/ > %{_libdir}/libfm/ fixed. > * -devel/-gtk-devel file splitting > - Well, I will say listing files in %_includedir/%name on -devel and > -gtk-devel in the current way is error-prone. Would you list files > in %_includedir/%name in some automated way like below? thanks a lot, this is very smart. > * pkgconfig .pc file was fixed upstream in 0.1.5 latest files: http://cwickert.fedorapeople.org/review/libfm.spec http://cwickert.fedorapeople.org/review/libfm-0.1.9-1.fc14.src.rpm For 0.1.9-1: ! gtk2 version specific dependency >> * BR/Requires >> - ">= 2.16.0" on "BR: gtk2-devel" is not needed because gtk2-devel >> in currently supported Fedora branches all satisfy this dependency: >> https://fedoraproject.org/wiki/Packaging/Guidelines#Explicit_Requires > The explicit requires guideline doesn't apply here as I'm not requiring a > library. Only the version number could be omitted, if all currently supported > Fedora branches fulfilled this requirement, but EPEL does not. - So I am talking about "if all currently supported...." item, and are you really considering EPEL? ( menu-cache does not even exist on EL-5 so I don't think you really care for EPEL. Also I am against that we should consider EPEL version dependency "by default" ) ! duplicate description > Why not? Only the first part of the description is the same, the rest is > different for the (sub)packages. IMO the description must be understandable for > every single package standalone because nether a package manager nor rpm -i > will show you the description of the required packages. - But you don't repeat the description written in "main" package on the rest -devel packages (and I think the description should not be repeated). I don't see any reason why you want to repeat the description on -gtk package when -gtk package depends on main package. ... Anyway the above 2 are not blockers. * Directory ownership issue - Still the following directories are not owned by any packages --------------------------------------------------------------- %{_libdir}/libfm/ (check -gtk subpackage) --------------------------------------------------------------- * Desktop file https://fedoraproject.org/wiki/Packaging/Guidelines#desktop-file-install_usage - Installed desktop file must be handled by desktop-file-{install,validate} ? By the way do you intend to install libfm only for F-13+ (as F-12 menu-cache does not satisfy the dependency)? (In reply to comment #9) > - So I am talking about "if all currently supported...." item, and are > you really considering EPEL? ( menu-cache does not even exist on > EL-5 so I don't think you really care for EPEL. Also I am against > that we should consider EPEL version dependency "by default" ) Yes, I intend bringing LXDE to EPEL (if possible). menu-cache shouldn't be a problem. > - But you don't repeat the description written in "main" package on > the rest -devel packages (and I think the description should not > be repeated). I think devel packages are different, they are not important to users. If somebody installs the devel packages, he already knows what libfm is. > I don't see any reason why you want to repeat the description on > -gtk package when -gtk package depends on main package. Why does it make a difference if the -gtk package depends on the base package? It is not important in the context of the description. Is there a benefit if i removed the first part of the description? "This package provides useful file manager-related GTK+ widgets." would be a little sparse. > * Directory ownership issue fixed. > > * Desktop file fixed. I updated the spec last week just before my LXDE talk @ CLT and obviously I was in a hurry and not very careful. New files: http://cwickert.fedorapeople.org/review/libfm.spec http://cwickert.fedorapeople.org/review/libfm-0.1.9-2.fc14.src.rpm > ? By the way do you intend to install libfm only for F-13+ (as F-12 menu-cache > does not satisfy the dependency)? menu-cache is itself is not a blocker, I could push 0.3.2 also to F-12. However I have no intentions to do this ATM because - there were incompatible API changes from 0.3.0 to 0.3.1 - there was an soname bump from 0.3.1 to 0.3.2 to indicate the API changes - only the new pcmanfm depends on libfm and I doubt you want to push a new major version to a stable release. It's on you to decide because you own pcmanfm. To me it is more important to have pcmanfm 1.0 in F13. Currently I'm using pcmanfm 0.9.3 and it is very stable. ATM it is still called pcmanfm2, so it can be installed in parallel to the old pcmanfm. There already is a patch to rename it back to the original name. Should we push it to F13 and if so, under which name? I would prefer using pcmanfm because the final version is scheduled for April. We could even go with 0.9.4 (beta 2) and update after release of F13. What do you think? While I have not checked your latest srpm yet, I mailed to you privately about updating pcmanfm on Fedora. Okay. - I think it is safer that "BR: desktop-file-utils" is explicitly written (yum log says currently desktop-file-utils is pulled in buildroot with the chain: desktop-file-utils <- redhat-menus <- menu-cache, however I think this dependency is so implicit) ----------------------------------------------------- This package (libfm) is APPROVED by mtasaka ----------------------------------------------------- If you don't mind, please as me as co-maintainer list. (In reply to comment #12) > - I think it is safer that "BR: desktop-file-utils" is explicitly > written Agreed, it's also part of the guidelines. (In reply to comment #13) > If you don't mind, please as me as co-maintainer list. Sure, your help is welcome. New Package CVS Request ======================= Package Name: libfm Short Description: GIO-based library for file manager-like programs Owners: cwickert mtasaka Branches: F-12 F-13 InitialCC: CVS done (by process-cvs-requests.py). libfm-0.1.9-2.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/libfm-0.1.9-2.fc13 Closing. libfm-0.1.9-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. we need this package for epel7 New Package CVS Request ======================= Package Name: libfm Short Description: GIO-based library for file manager-like programs Branches: epel7 InitialCC: You should file SCM admin requests in PKGDB. They haven't been processed from bugzilla tickets in some time. See http://fedoraproject.org/wiki/PackageDB_admin_requests |