Bug 229930 - Review Request: thunar-volman - Automatic management of removable drives and media for the Thunar file manager
Review Request: thunar-volman - Automatic management of removable drives and ...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kevin Fenzi
Fedora Package Reviews List
:
Depends On:
Blocks: 225083
  Show dependency treegraph
 
Reported: 2007-02-24 11:13 EST by Christoph Wickert
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-20 19:19:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
kevin: fedora‑review+
wtogami: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Christoph Wickert 2007-02-24 11:13:02 EST
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 11:23:30 EST
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 11:59:25 EST
>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 09:26:29 EST
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-03 22:47:29 EST
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 18:40:38 EST
(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 00:44:50 EDT
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 15:07:09 EDT
(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 15:54:09 EDT
(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 17:02:14 EDT
(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 19:19:53 EDT
29963 (thunar-volman): Build on target fedora-development-extras succeeded.

Note You need to log in before you can comment on or make changes to this bug.