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 450850

Summary: Review Request: move - Move file(s) to ~/.trash directory
Product: [Fedora] Fedora Reporter: pjp <pj.pandit>
Component: Package ReviewAssignee: 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: low    
Version: rawhideCC: fedora-package-review, mtasaka, notting, rc040203
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: 2008-07-25 10:40:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description pjp 2008-06-11 12:28:55 UTC
SPEC URL: http://pjp.dgplug.org/tools/move.spec
SRPM URL: http://pjp.dgplug.org/tools/move-1.2-1.fc8.src.rpm

Description: 
move moves the named file(s) to the ~/.trash directory. Trash is located
under the home directory of a user. It is a simple console based utility,
I wrote after deleting some files, which I couldn't retrieve back.
Move can also restore file(s) back to there original location. It has really
proved very handy to me.

This is my second fedora package, and am looking for a sponsor for this and my earlier package tlock. I'd really appreciate if somebody could come forward for the sponsorship.

tlock: https://bugzilla.redhat.com/show_bug.cgi?id=444952

Thank you!

Comment 1 Ralf Corsepius 2008-06-11 19:28:35 UTC
Some remarks:

1. I do not consider this application to be useful, because it aims at
implementing "yet another backing-up mv" replacement, using the "n-th"
non-standardized mechanism.

2. Naming an application "move" is a bad choice, because it's such a general
name that it's likely colliding with many other applications/scripts users may
have installed.

Provided this, I am not interested in formally reviewing this packages (This
shouldn't preventr others from doing so.).


Some technical remarks:

* The package doesn't acknowledge CFLAGS.

The cause is this bug in Makefile:
--- Makefile.am~	2008-06-11 21:18:07.000000000 +0200
+++ Makefile.am	2008-06-11 21:18:07.000000000 +0200
@@ -11,7 +11,7 @@
 ## 6. automake -ac --foreign
 ##
 
-CFLAGS = -D_GNU_SOURCE
+AM_CPPFLAGS = -D_GNU_SOURCE
 
 bin_PROGRAMS = move
 move_SOURCES = move.c movedb.c move.h movedb.ham:

* The spec file uses /sbin/install-info
=> Missing: Requires(pre) etc.



Comment 2 pjp 2008-06-12 07:02:39 UTC
  Hello Ralf, thanks for the technical comments.

I've replaced CFLAGS with the AM_CFLAGS. Please see the new files at

SPEC: http://pjp.dgplug.org/tools/move.spec
SORC: http://pjp.dgplug.org/tools/move-1.2.tar.gz
SRPM: http://pjp.dgplug.org/tools/move-1.2-2.fc8.src.rpm

> * The spec file uses /sbin/install-info
> => Missing: Requires(pre) etc.

About this Requires(pre), is it necessary if there is no %pre section in the
spec file?

Thanks!

Comment 3 Mamoru TASAKA 2008-06-12 15:28:18 UTC
Well, now the package itself seems okay (althogh I recommend to use
-------------------------------------------------------------
make install DESTDIR=$RPM_BUILD_ROOT INSTALL="install -p"
-------------------------------------------------------------
to keep timestamps on installed file), however I also think that
the name "move" is too generic...

Comment 4 pjp 2008-06-13 09:26:48 UTC
  Hello Mamoru, thanks for the comments.

I've made the changes. Please see the latest files at

SPEC: http://pjp.dgplug.org/tools/move.spec
SRPM: http://pjp.dgplug.org/tools/move-1.2-3.fc8.src.rpm

> however I also think that the name "move" is too generic...

  I do understand; But I really don't think it's practical to rename it..is it
that big a hurdle?

Thanks!


Comment 5 Patrice Dumas 2008-06-13 12:00:51 UTC
(In reply to comment #4)

>   I do understand; But I really don't think it's practical to rename it..is it
> that big a hurdle?

Yes, it is. Did you approach upstream to ask them why they used such
a generic name?

Comment 6 pjp 2008-06-13 13:07:37 UTC
> Yes, it is. Did you approach upstream to ask them why they used such
> a generic name?

  Well, when I wrote Move it seemed like a sensible name, and it still does to
me. It speaks about it's action, and is intuitive that way. Why is it that big a
deal?

Comment 7 Patrice Dumas 2008-06-13 13:14:31 UTC
It is too generic. Many programs can do the same than yours, none should
be called move, except if there is a standard endorsing the name.

Comment 8 pjp 2008-06-17 05:22:45 UTC
(In reply to comment #7)
> It is too generic. Many programs can do the same than yours, none should
> be called move, except if there is a standard endorsing the name.

  What name would you suggest? Trash??

  $ trash <file-name>


Comment 9 Jean-Fran├žois Martin 2008-06-17 07:22:30 UTC
>   What name would you suggest? Trash??
> 
>   $ trash <file-name>
> 

I have a package (not yet reviewed) that already use 
$ trash <file>

See https://bugzilla.redhat.com/show_bug.cgi?id=448122448122

Comment 10 pjp 2008-06-17 08:22:43 UTC
> I have a package (not yet reviewed) that already use 
> $ trash <file>

  Gawd...will ptrash do? I cann't believe I'm haggling for a name now.

Comment 11 Patrice Dumas 2008-06-17 10:00:40 UTC
ptrash would be perfect in my opinion.

Comment 12 pjp 2008-07-23 09:43:19 UTC
  Hello all,

Please see: https://bugzilla.redhat.com/show_bug.cgi?id=456385

Thank you!


Comment 13 Patrice Dumas 2008-07-25 10:40:03 UTC

*** This bug has been marked as a duplicate of 456385 ***