Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 229930

Summary: Review Request: thunar-volman - Automatic management of removable drives and media for the Thunar file manager
Product: [Fedora] Fedora Reporter: Christoph Wickert <cwickert>
Component: Package ReviewAssignee: Kevin Fenzi <kevin>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Package Reviews List <fedora-package-review>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: bugzilla, kevin, lxtnow
Target Milestone: ---Flags: kevin: fedora-review+
wtogami: fedora-cvs+
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-03-20 23:19:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 225083    

Description Christoph Wickert 2007-02-24 16:13:02 UTC
Spec URL: http://home.arcor.de/christoph.wickert/fedora/extras/review/SPECS/thunar-volman.spec
SRPM URL: http://home.arcor.de/christoph.wickert/fedora/extras/review/SRPMS/thunar-volman-0.1.2-1.fc7.src.rpm
Description: The Thunar Volume Manager is an extension for the Thunar file manager, which enables automatic management of removable drives and media. For example, if thunar-volman is installed and configured properly, and you plug in your digital camera, it will automatically launch your preferred photo application  and import the new pictures from the camera into your photo collection.

Comment 1 Christoph Wickert 2007-02-24 16:23:30 UTC
Sorry for the delay.

From a packager's point of view the package looks good to me, but the program
itself is not working reliable here. I often have problems unmounting devices,
but as I see the same problems in Gnome I'm not sure where the problem is (think
it's deeper in Hal/dbus in connection with SELinux) Please test this package
carefully, I need more feedback.

Also I'm not sure about the name: Rename the package to thunar-volman-plugin for
consistency?

Another question is whether it's correct to install thunar-volman to %{_bindir}.
IMO it should be in %{_libexecdir}, but this is something I have to talk about
with upstream first.

Comment 2 Xavier Lamien 2007-02-24 16:59:25 UTC
>Also I'm not sure about the name: Rename the package to thunar-volman-plugin for
>consistency?

Yes


>Another question is whether it's correct to install thunar-volman to %{_bindir}.
>IMO it should be in %{_libexecdir}, but this is something I have to talk about
>with upstream first.

I think so


Comment 3 Christoph Wickert 2007-02-25 14:26:29 UTC
1. I'm not sure if we really need to rename the package. On the one hand a
strictly consistent naming scheme would be nice, on the other hand it might be
_too_ strict. The naming guidelines only say that we need a parent like xfce4-*,
but we don't need the *-plugin. thunar-volman also is the upstream name.

2. I think so too, so I patched thunar-volman to install to libexecdir, but this
doesn't work as long as Thunar looks for the executable in path. This is
something  that needs to be changed in Thunar and requires more discussion.

Comment 4 Kevin Fenzi 2007-03-04 03:47:29 UTC
Sorry it took so long for me to chime in on this one... 

1. I don't think I care much. Sticking with the upstream name has some value
however (ie, people reading upstream docs will look for that package name, etc),
so I think it's marginally better to stick with thunar-volman. 

2. Is thunar-volman useful in any way by itself or to other programs? 
If it's just simply a Thunar plugin only, then libexecdir does make more sense. 
If it's useful otherwise, then perhaps bindir is ok. 
Have you had a chance to bring this up to upstream? 


Comment 5 Christoph Wickert 2007-03-10 23:40:38 UTC
(In reply to comment #4)
> Sorry it took so long for me to chime in on this one... 

Never mind, I'm not in a hurry since I'm very busy @ work. Sorry.

> 1. I don't think I care much. Sticking with the upstream name has some value
> however (ie, people reading upstream docs will look for that package name, etc),

I would fix that with a Provides: thunar-volman as I'm doing for all my packages
that have a different name from upstream.

> so I think it's marginally better to stick with thunar-volman. 

+1

> 2. Is thunar-volman useful in any way by itself or to other programs? 

You can call thunar-volman from the command line (syntax is just like exo-mount,
exo-unmount or exo-eject) but it's not really useful for every day work. I'm
afraid it needs to be in bindir due to upstream approach to write programs that
look for these helpers in $PATH.

> Have you had a chance to bring this up to upstream? 

Not yet.

Comment 6 Kevin Fenzi 2007-03-15 04:44:50 UTC
OK - Package meets naming and packaging guidelines
OK - Spec file matches base package name.
OK - Spec has consistant macro usage.
OK - Meets Packaging Guidelines.
OK - License (GPL)
OK - License field in spec matches
OK - License file included in package
OK - Spec in American English
OK - Spec is legible.
OK - Sources match upstream md5sum:
910de35c398f70b66b38803bdfdd26f1  thunar-volman-0.1.2.tar.bz2
910de35c398f70b66b38803bdfdd26f1  thunar-volman-0.1.2.tar.bz2.1
OK - BuildRequires correct
OK - Spec handles locales/find_lang
OK - Package has %defattr and permissions on files is good.
OK - Package has a correct %clean section.
OK - Package has correct buildroot
OK - Package is code or permissible content.
OK - Packages %doc files don't affect runtime.

OK - Package compiles and builds on at least one arch.
OK - Package has no duplicate files in %files.
OK - Package doesn't own any directories other packages own.
OK - Package owns all the directories it creates.
OK - No rpmlint output.
OK - final provides and requires are sane.

SHOULD Items:

OK - Should build in mock.
OK - Should build on all supported archs
OK - Should function as described.
OK - Should have dist tag
OK - Should package latest version

Issues:

1. Is the "Requires:       Thunar >= %{thunarver}" needed?
rpm picks up on the requires of "libthunar-vfs-1.so.2" which pulls in Thunar.


Comment 7 Christoph Wickert 2007-03-20 19:07:09 UTC
(In reply to comment #6)
> Issues:
> 
> 1. Is the "Requires:       Thunar >= %{thunarver}" needed?
> rpm picks up on the requires of "libthunar-vfs-1.so.2" which pulls in Thunar.

It's only needed for the versioned (Build)Requires:. For example Thunar 0.8.0 is
quite different from 0.6.0 without change of soname, so I'd like to leave it in.

Comment 8 Kevin Fenzi 2007-03-20 19:54:09 UTC
(In reply to comment #7)

Yeah, I guess that makes sense. We know that we aren't going to build for an
older Thunar here, but if someone took this spec and tried to build it
themselves with an older one it could blow up. 

So, I see no further blockers, this package is APPROVED.
Don't forget to use the new CVS method and close this review request RAWHIDE
once it's been imported and built. 

Comment 9 Christoph Wickert 2007-03-20 21:02:14 UTC
(In reply to comment #8)
> We know that we aren't going to build for an
> older Thunar here, but if someone took this spec and tried to build it
> themselves with an older one it could blow up. 

First of all I thinking of people, who try to install this package on John Doe's
linux or whatever. I know I can't stop them, but I want to make as hard as
possible. :)

BTW: Thunar-volman now works very reliable here. Seems like the problems were
caused by a fstab entry that mounts an iso image. After commenting this line out
the problems disappeared both in gnome and xfce.


New Package CVS Request
=======================
Package Name: thunar-volman
Short Description: Automatic management of removable drives and media for the
Thunar file manager
Owners: fedora@christoph-wickert.de
Branches: FC-6
InitialCC: kevin@tummy.com

Comment 10 Christoph Wickert 2007-03-20 23:19:53 UTC
29963 (thunar-volman): Build on target fedora-development-extras succeeded.