Bug 448122 - Review Request: trash-cli - Command line trashcan (recycle bin) interface
Review Request: trash-cli - Command line trashcan (recycle bin) interface
Status: CLOSED DUPLICATE of bug 508750
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE-DEADREVIEW
  Show dependency treegraph
 
Reported: 2008-05-23 11:55 EDT by Jean-François Martin
Modified: 2009-06-29 14:11 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-15 14:36:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
error from ./trash.py (2.43 KB, text/plain)
2008-06-25 03:24 EDT, Patrice Dumas
no flags Details

  None (edit)
Description Jean-François Martin 2008-05-23 11:55:46 EDT
Spec URL: http://lokthare.fedorapeople.org/temp/trash.spec
SRPM URL: http://lokthare.fedorapeople.org/temp/trash-0.1.10-1.fc9.src.rpm
Description: Command line interface to trash compatible with Trash Spec from FreeDesktop.org
Comment 1 Patrice Dumas 2008-06-17 06:02:03 EDT
The name of this package is also a bit too generic, though not that much.
Could upstream change it to be less generic?
Comment 2 Jean-François Martin 2008-06-18 16:08:11 EDT
Ok, i have asked the author, it's seems possible to change the name.
Comment 3 Jean-François Martin 2008-06-21 16:48:39 EDT
I have receive an email of the author suggesting to use trash-cli for the name.
Does it seem ok?
Comment 4 Patrice Dumas 2008-06-21 17:21:31 EDT
Looks good to me
Comment 5 Jean-François Martin 2008-06-23 00:15:11 EDT
Spec URL: http://lokthare.fedorapeople.org/temp/trash-cli.spec
SRPM URL: http://lokthare.fedorapeople.org/temp/trash-cli-0.1.10.28-1.fc9.src.rpm

- Update to the new release
- Change to the new name
Comment 6 Patrice Dumas 2008-06-24 15:49:33 EDT
It seems to me that the url is 
URL:            http://www.andreafrancia.it/trash/
and that the source is
Source0:        http://downloads.sourceforge.net/bluetrash/%{name}-%{version}.tar.gz

The timestamp of the source archive is not kept:
 14458 jun 23 06:05 ../SOURCES/trash-cli-0.1.10.28.tar.gz
 14458 jun 21 13:48 trash-cli-0.1.10.28.tar.gz
You can use spectool -g or wget -N.

The name of the command should also be trash-cli. The common namespace 
extends to the commands in %{_bindir}.

rpmlint says:
trash-cli.noarch: W: no-documentation

I propose:
%doc COPYING README

You could use the page at
http://www.andreafrancia.it/trash/
as documentation.

The license is GPL+ since there is nothing specified in the source files.
As a side note, it is better to have the GPL headers in source files,
authors may not be able to hold in court otherwise.

I tried to run the file ./test.py in-source, but it failed. Is it normal?

In the test.bash file there is a security issue, files with reproducible
names are created in /tmp, they should instead be cerated in the current
directory.
Comment 7 Patrice Dumas 2008-06-24 15:50:23 EDT
Also a dot is missing at the end of the %description.
Comment 8 Patrice Dumas 2008-06-24 15:52:27 EDT
And it is a noarch package so the CFLAGS= is unneeded... as said in 
the comment ;-)
Comment 9 Andrea Francia 2008-06-24 19:27:36 EDT
(In reply to comment #6)
> The license is GPL+ since there is nothing specified in the source files.
> As a side note, it is better to have the GPL headers in source files,
> authors may not be able to hold in court otherwise.
I'm working on it.

> I tried to run the file ./test.py in-source, but it failed. Is it normal?
It's not normal. 
Could you provide the error message?

> In the test.bash file there is a security issue, files with reproducible
> names are created in /tmp, they should instead be cerated in the current
> directory.
I'm working on it.
Comment 10 Andrea Francia 2008-06-24 19:41:22 EDT
> The name of the command should also be trash-cli. 
The name of the package is trash-cli which means "Interacting with the
Freedesktop trashcan trough the Command Line Interface"

The name of the main command is 'trash' without "-cli".
The command is used is this way:
 $ trash this-file
That means: "trash this-file in the trashcan", there is no reason to append the
"-cli" suffix to the main command. You are already using the Command Line
Interface. 

For example the commands to remove, move, copy, or touch files are: "rm", "mv",
"cp" and "touch". There is not an "rm-cli" nor a "cp-cli".
Comment 11 Ralf Corsepius 2008-06-25 01:30:14 EDT
(In reply to comment #10)
> For example the commands to remove, move, copy, or touch files are: "rm", "mv",
> "cp" and "touch". There is not an "rm-cli" nor a "cp-cli".
Unlike your "trash" application, these applications are ISO/IEEE/POSIX
standardized, widely used and have a long (25+ years) history.

That said, I agree with comment #1, upstream should consider to rename their
"trash" application into something less generic.
Comment 12 Andrea Francia 2008-06-25 02:46:00 EDT
(In reply to comment #11)
> Unlike your "trash" application, these applications are ISO/IEEE/POSIX
> standardized, widely used and have a long (25+ years) history.
"lsmod" is not so old and is not called lsmod-cli, its name reflet what it does
(list the modules). Is "lsmod" ISO, IEEE or POSIX standardized?
The "rename" command present in the Fedora is called "rename", not
"yet-another-renamer", the rename command is not so old nor standardized. In
fact the "rename" found in other distribution is from a different package with
another interface. 
Instead the trash-cli package will be present soon in at least two distribution
(Fedora and Ubuntu) with the same command names. 

Another not so old example are "lspci" that list the PCI devices.

In my opinion each command name should reflect what the command does. 

> That said, I agree with comment #1, upstream should consider to rename their
> "trash" application into something less generic.
There is not a "trash" *application* there is a package named "trash-cli" that
provides four commands (implemented as executables):
 - trash (that trashes files)
 - list-trash (that list the trashed files)
 - empty-trash (that empty the trashcan(s))
 - restore-trash (that restore a trashed file)

You think that I should rename all adding -cli?

The Freedesktop Trash Specification are followed by KDE, soon by GNOME, and by
other Desktop Enviroment. 
I think is enough a standard that name the command line interface commands to
interact with it without adding some strange suffix.
Comment 13 Patrice Dumas 2008-06-25 03:24:20 EDT
Created attachment 310234 [details]
error from ./trash.py
Comment 14 Patrice Dumas 2008-06-25 03:41:56 EDT
(In reply to comment #12)
> (In reply to comment #11)
> > Unlike your "trash" application, these applications are ISO/IEEE/POSIX
> > standardized, widely used and have a long (25+ years) history.
> "lsmod" is not so old and is not called lsmod-cli, its name reflet what it does
> (list the modules). Is "lsmod" ISO, IEEE or POSIX standardized?

lsmod is specific enough.

> The "rename" command present in the Fedora is called "rename", not
> "yet-another-renamer", the rename command is not so old nor standardized. In

It is in util-linux-ng, so this is not something very problematic, it 
is going to be a defacto standard.

> fact the "rename" found in other distribution is from a different package with
> another interface. 

That's an issue, but I'd say that in that case the rename from util-linux-ng
should be considerd as the reference. I may be wrong, I don't know this
very well.

There are other better example, however, ren is such an example, and it
is my bad since I reviewed and accepted it, certainly before Ralf made me
aware of the naming issues. Another example is GMT, but in that case I think
that it has enough precedence since this application is very old.


> Instead the trash-cli package will be present soon in at least two distribution
> (Fedora and Ubuntu) with the same command names. 

That's not a good reason.

> Another not so old example are "lspci" that list the PCI devices.

But this is not a non-specific name.

> In my opinion each command name should reflect what the command does. 

As far as possible.

> > That said, I agree with comment #1, upstream should consider to rename their
> > "trash" application into something less generic.
> There is not a "trash" *application* there is a package named "trash-cli" that
> provides four commands (implemented as executables):
>  - trash (that trashes files)
>  - list-trash (that list the trashed files)
>  - empty-trash (that empty the trashcan(s))
>  - restore-trash (that restore a trashed file)
> 
> You think that I should rename all adding -cli?

No, only trash in my opinion. The others are specific enough. They could 
be even more specific, but at the expense of usability. The right level 
of non-genericity is something subjective, my feeling is that 
trash is not right since it may clash easily with an application doing something
very different, and be used in a standard in the future, be
is a defacto standard like what is in some basic package like util-linux,
coreutils, bash buil-in and a few others or a real standard.

> The Freedesktop Trash Specification are followed by KDE, soon by GNOME, and by
> other Desktop Enviroment. 
> I think is enough a standard that name the command line interface commands to
> interact with it without adding some strange suffix.

The command name is not standardised, isn't it? Not the command line
interface? If it is so, then the alternative system should be used, 
but I don't think this is the case here.
Comment 15 Andrea Francia 2008-06-25 14:36:17 EDT
(In reply to comment #14)
> The right level 
> of non-genericity is something subjective, my feeling is that 
> trash is not right since it may clash easily with an application doing something
> very different, and be used in a standard in the future, be
> is a defacto standard like what is in some basic package like util-linux,
> coreutils, bash buil-in and a few others or a real standard.

When a such standard will be created I can accommodate the trash-cli command
names to do not conflict with the standard.

The util-linux is standard only on Linux based distribution. Debian which is not
Linux specific doesn't have the util-linux 'rename' which is a command with a
interface so poorly designed that doesn't allows to grows (for example you
cannot add any switches to rename synopsys without broking the existing interface). 

At the present 'trash' is the best (in terms of usability) name I've found for
the command that trashes files. It's important for me provide a usable interface
to facilities of trash-cli package. If someone could suggest me a name that is
good in terms of usability and is not so generic please tell me.
Comment 16 Andrea Francia 2008-06-25 14:54:37 EDT
(In reply to comment #13)
> Created an attachment (id=310234) [edit]
> error from ./trash.py
> 
Many thanks for reporting the errors, they will be very useful to me.

Could I ask to provide me only another information? I need the output of "df" on
the machine where the test 'testListVolumes' fails. Or at least I need to know
that machine the output of the commands invocation df and df -P differs.
If this is the case I will know that the problem is already solved.
Comment 17 Patrice Dumas 2008-06-25 15:00:07 EDT
(In reply to comment #15)
> (In reply to comment #14)
> > The right level 
> > of non-genericity is something subjective, my feeling is that 
> > trash is not right since it may clash easily with an application doing something
> > very different, and be used in a standard in the future, be
> > is a defacto standard like what is in some basic package like util-linux,
> > coreutils, bash buil-in and a few others or a real standard.
> 
> When a such standard will be created I can accommodate the trash-cli command
> names to do not conflict with the standard.

Anticipating by not using generic names will help not forcing users 
to redo all their scripts.

> The util-linux is standard only on Linux based distribution. Debian which is not
> Linux specific doesn't have the util-linux 'rename' which is a command with a
> interface so poorly designed that doesn't allows to grows (for example you
> cannot add any switches to rename synopsys without broking the existing
interface). 

I don't want to argue about that example, it may very well be that using
rename from util-linux-ng is a bad choice and that it should be discussed
with upstream and in the mean time renamed. If you fill a bug against 
util-linux-ng I'd like to be in CC to see what the maintainer says and
be able to argue on that case. As I said above there is 'ren' in fedora
which is a bad idea already, but it is not a reason to let other generic 
names enter the distro.
 
> At the present 'trash' is the best (in terms of usability) name I've found for
> the command that trashes files. It's important for me provide a usable interface
> to facilities of trash-cli package. If someone could suggest me a name that is
> good in terms of usability and is not so generic please tell me.

I can propose
to-trash
in-trash
trash-dump
trash-put
I can try other names if none fits (but I am not very good at that
be it only because I am not a native english speaker).
Comment 18 Patrice Dumas 2008-06-25 15:01:35 EDT
(In reply to comment #16)
> (In reply to comment #13)
> > Created an attachment (id=310234) [edit] [edit]
> > error from ./trash.py
> > 
> Many thanks for reporting the errors, they will be very useful to me.
> 
> Could I ask to provide me only another information? I need the output of "df" on
> the machine where the test 'testListVolumes' fails. Or at least I need to know
> that machine the output of the commands invocation df and df -P differs.
> If this is the case I will know that the problem is already solved.

Here are the df and df -P outputs:

[dumas@localhost ~]$ df
Sys. de fich.        1K-blocs       Occupé Disponible Capacité Monté sur
/dev/sda2              9469180   8845188    135216  99% /
tmpfs                   251616         0    251616   0% /dev/shm
/dev/sda6             37418568  30076264   5410892  85% /home
[dumas@localhost ~]$ df -P
Sys. de fich.      1024-blocs        Capacité Disponible Occupée Monté sur
/dev/sda2              9469180   8845188    135216      99% /
tmpfs                   251616         0    251616       0% /dev/shm
/dev/sda6             37418568  30076264   5410892      85% /home


Comment 19 Andrea Francia 2008-09-02 18:48:01 EDT
(In reply to comment #17)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > The right level 
> > > of non-genericity is something subjective, my feeling is that 
> > > trash is not right since it may clash easily with an application doing something
> > > very different, and be used in a standard in the future, be
> > > is a defacto standard like what is in some basic package like util-linux,
> > > coreutils, bash buil-in and a few others or a real standard.
> > 
> > When a such standard will be created I can accommodate the trash-cli command
> > names to do not conflict with the standard.
> 
> Anticipating by not using generic names will help not forcing users 
> to redo all their scripts.

So I should reduce the usability of a program for something that could (or could not) happen in the future?

I never heard about a list of UNIX commands names reserved for future uses. 

Can we relax this constraing putting trash-cli in the extra packages?
Comment 20 Patrice Dumas 2008-09-03 06:25:27 EDT
There are no extra packages anymore (since F-7, if I recall well).
Also Fedora is not UNIX, there is no such list, but I think that it is our responsibility as packagers to be proactive in avoiding clashes. At least this 
is my responsability. I miss some, and sometime I don't have time to jump on all submissions, and some packagers don't care.

In any case if you find somebody willing to accept the package with this
command name no problem. It won't be me, but there are many other fedora
packagers.

For an example, there is
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00127.html
Comment 21 Jean-François Martin 2008-10-01 16:37:54 EDT
Hi,

first, i want to apologize for not respond to this review.

I will update the package this weekend.
If Patrice really don't want to accept this package with this name, i will try to find a reviewer who would accept this.
Comment 22 Patrice Dumas 2008-10-01 16:54:39 EDT
(In reply to comment #21)
> Hi,
> 
> first, i want to apologize for not respond to this review.
> 
> I will update the package this weekend.
> If Patrice really don't want to accept this package with this name, i will try
> to find a reviewer who would accept this.

You can drop a mail on fedora-devel-list stating th enature of
the disagreement and asking for a reviewer who would agree with 
the name, or I can do it if you want to.
Comment 23 Jean-François Martin 2008-10-01 17:58:04 EDT
(In reply to comment #22)
> You can drop a mail on fedora-devel-list stating th enature of
> the disagreement and asking for a reviewer who would agree with 
> the name, or I can do it if you want to.

I will do it this weekend after having updated the package. Thanks for the offer.
Comment 24 Jean-François Martin 2008-10-04 19:11:56 EDT
Spec URL: http://lokthare.fedorapeople.org/temp/trash.spec
SRPM URL: http://lokthare.fedorapeople.org/temp/trash-cli-0.1.10.r55-1.fc9.src.rpm

- The project URL has changed
- Update to the new release

Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=861510

I have send a mail to devel-list asking for a reviewer who would accept this package : https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00216.html
Comment 25 Jean-François Martin 2008-10-09 08:54:45 EDT
I have send the mail 5 days ago, i don't think a reviewer will accept it.

I will try to convince upstream to change the name of the "trash" command. If they don't want to change, i will rename it in the package.

In this case, should I edit http://distributions.freedesktop.org/wiki/ConflictingFiles and send a mail to the distributions mailing list of FreeDesktop as someone advise me in devel ml ?
Comment 26 Jean-François Martin 2008-10-09 09:55:29 EDT
I have received a answer from upstream, they will change the command. Will wait next release and update the package.
Comment 27 Patrice Dumas 2008-10-09 11:30:42 EDT
(In reply to comment #25)
> I have send the mail 5 days ago, i don't think a reviewer will accept it.

You're really out of luck, or maybe it is because it stirred some 
debate, since I see other packages with very debatable names entering
the distro which shows that many reviewers don't care (I don't have the 
time to comment on all th ereviews, especially these days I am very 
busy)... In fact my interest for the package turned out to be a 
disadvantage :-/
Comment 28 Andrea Francia 2008-10-09 12:03:50 EDT
(In reply to comment #27)
> (In reply to comment #25)
> > I have send the mail 5 days ago, i don't think a reviewer will accept it.
> 
> You're really out of luck, or maybe it is because it stirred some 
> debate, since I see other packages with very debatable names entering
> the distro which shows that many reviewers don't care (I don't have the 
> time to comment on all th ereviews, especially these days I am very 
> busy)... In fact my interest for the package turned out to be a 
> disadvantage :-/

C'est la vie. Thanks fot the interest.
Comment 29 Andrea Francia 2008-12-23 18:54:24 EST
I prepared the next release, you can see it at:

   http://pypi.python.org/pypi/trash-cli/0.2.1.dev-r82

Instruction for building the rpm:

 $ wget http://pypi.python.org/packages/source/t/trash-cli/trash-cli-0.2.1.dev-r82.tar.gz
 $ tar xvfz trash-cli-0.2.1.dev-r82.tar.gz
 $ cd trash-cli-0.2.1.dev-r82/
 $ python setup.py bdist_rpm
 $ ls dist/trash-cli-0.2.1.dev*.rpm
 dist/trash-cli-0.2.1.dev_r82-1.noarch.rpm
 dist/trash-cli-0.2.1.dev_r82-1.src.rpm

Running unit test:

 $ nosetests
 ......................................................
 ----------------------------------------------------------------------
 Ran 54 tests in 1.250s

 OK

Running command test:
WARNING: these test will wipe-out your trashcan

 $ cd command-test
 $ bash mount-test-volume.sh
 [sudo] password for andrea:
 
 $ bash trash-file-test.bash
 #
 # Test report
 #
 tests passed: 132
 tests failed: 0
 tests total:  132
 success rate: 100%

 $ sudo umount test-volume
 [sudo] password for andrea:
Comment 30 Andrea Francia 2009-01-04 10:41:21 EST
After some discussion and consultation with other people, in particular with Ben Finney[1] I decided to rename the trash-file command to trash-put.

[1] http://lists.freedesktop.org/archives/distributions/2009-January/000285.html

The updated package can be found on pipy:

    http://pypi.python.org/pypi/trash-cli/

You can use the same instructions as before for installing and testing the package. Taking care of using the new download url[2], and using the test script with the updated name: 

   bash trash-put-test.bash

[2] http://pypi.python.org/packages/source/t/trash-cli/trash-cli-0.2.1.dev-r143.tar.gz#md5=7ec53b0039a41215d0e546c19f667f41
Comment 31 Patrice Dumas 2009-01-08 16:45:53 EST
Great. I have left fedora, but I can still do at least part of the review.
However Jean-François has to prepare a .src.rpm.

Jean-François did you package the latest version?
Comment 32 Andrea Francia 2009-03-14 09:41:01 EDT
I don't think that Jean-François is going to provide the latest version. Maybe he's working to something else. I asked to fedora-devel list if there is someone interested in packaging the software.
Comment 33 Terje Røsten 2009-03-14 17:33:59 EDT
If someone wants to maintain the package:

Did not find spec and srpm from #25, redid the whole thing:

spec: http://terjeros.fedorapeople.org/trash-cli/trash-cli.spec
srpm: http://terjeros.fedorapeople.org/trash-cli/trash-cli-0.11.0-1.r199.fc10.src.rpm
koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=1241694


Note: not tested at all.
Comment 34 Jason Tibbitts 2009-03-15 14:36:59 EDT
No point in having an open review ticket when there's nobody submitting a package.
Comment 35 Matěj Cepl 2009-03-23 10:17:27 EDT
(In reply to comment #33)
> If someone wants to maintain the package:
> 
> Did not find spec and srpm from #25, redid the whole thing:
> 
> spec: http://terjeros.fedorapeople.org/trash-cli/trash-cli.spec
> srpm:
> http://terjeros.fedorapeople.org/trash-cli/trash-cli-0.11.0-1.r199.fc10.src.rpm
> koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=1241694

why won't you file the packagereview and maintain the package yourself?
Comment 36 Matěj Cepl 2009-03-23 10:20:18 EDT
[matej@viklef trash-cli-0.11.0]$ trash-list 
Traceback (most recent call last):
  File "/usr/bin/trash-list", line 21, in <module>
    from trashcli.trash import trashcan
  File "/usr/lib/python2.5/site-packages/trashcli/trash.py", line 42, in <module>
    from .filesystem import Volume
  File "/usr/lib/python2.5/site-packages/trashcli/filesystem.py", line 27, in <module>
    import unipath
ImportError: No module named unipath
[matej@viklef trash-cli-0.11.0]$
Comment 37 Andrea Francia 2009-03-23 18:15:49 EDT
The trash-cli package depends from the python unipath package.
Comment 38 Andrea Francia 2009-03-23 18:18:17 EDT
(In reply to comment #35)
> why won't you file the packagereview and maintain the package yourself?  

It would be great if someone decide to maintain the RPM package.
Comment 39 Jason Tibbitts 2009-06-29 14:11:12 EDT

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

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