Bug 567257

Summary: Review Request: libfm - GIO-based library for file manager-like programs
Product: [Fedora] Fedora Reporter: Christoph Wickert <christoph.wickert>
Component: Package ReviewAssignee: Mamoru TASAKA <mtasaka>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: 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
Spec URL: http://cwickert.fedorapeople.org/review/libfm.spec
SRPM URL: http://cwickert.fedorapeople.org/review/libfm-0.1-1.fc14.src.rpm
Description: LibFM is a GIO-based library used to develop file manager-like programs. It is developed as the core of next generation PCManFM and takes care of all file-related operations such as copy & paste, drag & drop, file associations or thumbnail support. By utilizing glib/gio and gvfs, libfm can access remote filesystems supported by gvfs.


Nore: The reason for splitting this into libfm and libfm-gtk is that it is going to be splitted upstream too. Maybe libfm-qt or libfm-etk will follow.

Comment 1 Mamoru TASAKA 2010-02-22 13:45:28 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 ?

Comment 2 Christoph Wickert 2010-02-22 14:10:57 UTC
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.

Comment 3 Mamoru TASAKA 2010-02-23 06:44:40 UTC
Will review, however please wait...

Comment 4 Christoph Wickert 2010-02-23 12:24:43 UTC
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.

Comment 5 Mamoru TASAKA 2010-02-25 17:04:40 UTC
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.

Comment 6 Mamoru TASAKA 2010-03-08 16:57:25 UTC
ping?

Comment 7 Christoph Wickert 2010-03-08 17:09:21 UTC
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.

Comment 8 Christoph Wickert 2010-03-19 22:51:58 UTC
(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

Comment 9 Mamoru TASAKA 2010-03-20 17:15:09 UTC
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)?

Comment 10 Christoph Wickert 2010-03-21 01:48:12 UTC
(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?

Comment 11 Mamoru TASAKA 2010-03-21 05:31:09 UTC
While I have not checked your latest srpm yet, I mailed to you
privately about updating pcmanfm on Fedora.

Comment 12 Mamoru TASAKA 2010-03-21 14:45:11 UTC
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
-----------------------------------------------------

Comment 13 Mamoru TASAKA 2010-03-21 14:46:15 UTC
If you don't mind, please as me as co-maintainer list.

Comment 14 Christoph Wickert 2010-03-21 15:01:09 UTC
(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:

Comment 15 Jason Tibbitts 2010-03-21 15:41:35 UTC
CVS done (by process-cvs-requests.py).

Comment 16 Fedora Update System 2010-03-21 16:20:53 UTC
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

Comment 17 Mamoru TASAKA 2010-03-22 16:04:06 UTC
Closing.

Comment 18 Fedora Update System 2010-03-23 23:26:52 UTC
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.

Comment 19 Than Ngo 2016-06-01 12:22:28 UTC
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:

Comment 20 Jason Tibbitts 2016-06-01 19:00:53 UTC
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