Bug 448122

The name of this package is also a bit too generic, though not that much.
Could upstream change it to be less generic?

Ok, i have asked the author, it's seems possible to change the name.

I have receive an email of the author suggesting to use trash-cli for the name.
Does it seem ok?

Looks good to me

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

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.

Also a dot is missing at the end of the %description.

And it is a noarch package so the CFLAGS= is unneeded... as said in 
the comment ;-)

(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.

> 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".

(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.

(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.

Created attachment 310234 [details]
error from ./trash.py

(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.

(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.

(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.

(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).

(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

(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?

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

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.

(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.

(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.

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

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 ?

I have received a answer from upstream, they will change the command. Will wait next release and update the package.

(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 :-/

(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.

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:

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

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?

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.

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.

No point in having an open review ticket when there's nobody submitting a package.

(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?

[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]$

The trash-cli package depends from the python unipath package.

(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.

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