Bug 444366 (deco)

rpmlint outputs the following ... this is due to how the application matches
file extensions with how to extract them ..

[steve@tachikoman i386]$ rpmlint deco-0.8.1-1.fc8.i386.rpm 
deco.i386: E: compressed-symlink-with-wrong-ext /usr/share/deco/tbz tar.bz2
deco.i386: E: compressed-symlink-with-wrong-ext /usr/share/deco/taz tar.gz
deco.i386: E: compressed-symlink-with-wrong-ext /usr/share/deco/tar.z tar.gz
deco.i386: E: compressed-symlink-with-wrong-ext /usr/share/deco/tgz tar.gz
[steve@tachikoman i386]$ 

Just a note after a quick glance over the spec:
- "Source0:" should include the full path to the downloadable source file, i.e.
 http://hartlich.com/deco/download/deco-0.8.1.tar.gz
- you should not use absolute paths in the spec, but macros. hence all
occurrences of "/usr" should be replaced by "%{_prefix}", "/usr/bin/" by
"%_bindir" and "/usr/share/" by "%{_datadir}"
- /usr/share/deco is not owned by anyone

 And just as a mater of curiosity: wouldn't it be simpler to use
"%{_datadir}/deco/*" (or even "%{_datadir}/%{name}") in %files, instead of
listing all individual components ?

I've uploaded an updates spec/srpm fixing the issues found  ...

Spec URL: http://www.stevemilner.org/tmp/deco.spec
SRPM URL: http://www.stevemilner.org/tmp/deco-0.8.1-2.fc8.src.rpm

The crename and symlinktarget C programs do the same than rename 
(util-linux-ng) and readlink (coreutils). 

So I'd suggest using those directly.

Another issue is that %{_datadir} is not used, instead %{_prefix}/share
is used. There are many ways to fix that. The cleanest would certainly 
be to add a makefile variable for PREFIX/share and substitute is in 
deco.in, especially if you can submit such patch upstream.

Thanks Patrice,

Are these items that need to be worked on (or patches accepted) upstream before
this package can be approved?

These issues have to be worked on, but not necessarily upstream.
It is better if you submit patches upstream at the same time you 
use them in the package, but it is not an obligation.

Using directly rename and readlink need not to be done upstream
since they may be problematic for portability. I would simply 
do a sed substitution on deco.

I think it's a bad idea to have Requires: on extractors of all supported file
types.  The current list of "flac, arj, arc, cabextract, lzma" already looks
hopelessly incomplete and at the same time personally I'd already be annoyed if
installing deco would pull in things like arj or arc.  So FWIW, +1 to not
depending on *any* archivers.

On the other hand, if the supported archive types can be enabled on the fly by
placing symlinks somewhere (that's what I understood from the discussion,
haven't looked at the package), perhaps consider using %triggers (still without
dependencies!), see eg. the bash-completion package.

(In reply to comment #7)
> I think it's a bad idea to have Requires: on extractors of all supported file
> types.  The current list of "flac, arj, arc, cabextract, lzma" already looks
> hopelessly incomplete and at the same time personally I'd already be annoyed if
> installing deco would pull in things like arj or arc.  So FWIW, +1 to not
> depending on *any* archivers.

Agreed.

> On the other hand, if the supported archive types can be enabled on the fly by
> placing symlinks somewhere (that's what I understood from the discussion,
> haven't looked at the package), perhaps consider using %triggers (still without
> dependencies!), see eg. the bash-completion package.

This looks complicated to me. It seems to me that patching deco to have
a way to tell that the program is not there and have a nice error message
in that case would be better.

Any progress here?

Sorry, no I have not made any progress on this.

Ping?

Upstream changed a lot, now it is a C program and there is a separate
deco-archive.

Sorry folks but I'm going to bow out on this :-/ ... anyone else is free to pick it up and take it from here if they have the time.

I think this package now belongs to a 3rd party repo since it now supports non-free formats such as .rar
It can be patched to support only free formats and a non-free subpackage can be made and put in a 3rd party repo but that's unnecessarily more work.
I can take the package over at rpmfusion now if you close the bug here. Thanks.

Nevermind, even bash-completion has references to non-free packages such as unrar. Since that package is allowed in Fedora, this one can be too. I will take the package over here.

Thanks Orcan!

No problem Steve, we can still maintain it together if you want.
Here are the new files:
SPEC: http://oget.fedorapeople.org/review/deco.spec
SRPM: http://oget.fedorapeople.org/review/deco-1.5.6-1.fc9.src.rpm

There are three types of rpmlint errors/warnings, which can all be ignored:

   * deco.x86_64: W: dangerous-command-in-%trigger
   I used the %trigger functions as Ville suggested. This results in these 
   "dangerous commands".

   * deco.x86_64: E: zero-length 
   All zero length files are needed by the program

   * deco.x86_64: E: compressed-symlink-with-wrong-ext
   These kinds of files are needed by the program too.

The deco program itself doesn't mean much without the deco-archive. Hence in this package I included both of them.

Please let me know if you have any suggestions for improvement.

Package is in good condition. My notes:

* Source0 must be given in full URL.

* I would include the test.py and demo.py inside the %doc files, because they give a nice demonstration about how gnuplot-py should be used. You don't need to remove shebangs from them. Just do:
   mv %{buildroot}%{python_sitelib}/Gnuplot/demo.py doc/Gnuplot/
   mv %{buildroot}%{python_sitelib}/Gnuplot/test.py doc/Gnuplot/
in the %install section. Or maybe you may want to install them inside an "examples" directory under %doc.

Otherwise the package is good to go.

Oops, sorry, comment #18 belongs to some other bug. Please ignore.

I separated deco-archive from deco (Bug# 469134). Therefore one of them will not need to be rebuilt everytime the other one is updated by the upstream. 

Right now, there is a circular dependency between the two packages. I'm not sure if this is allowed. But obviously they both need each other. Any ideas are welcome.

Also, because of the separation, the rpmlint output for deco is silent now. Those messages made a trip to deco-archive.

The new files are:
SPEC: http://oget.fedorapeople.org/review/deco.spec
SRPM: http://oget.fedorapeople.org/review/deco-1.5.6-2.fc9.src.rpm

SPEC: http://oget.fedorapeople.org/review/deco.spec
SRPM: http://oget.fedorapeople.org/review/deco-1.5.7-1.fc9.src.rpm

%changelog
- Version update

License should be GPLv3 instead of GPL+.

Having the scripts in /usr/share/deco and the trigger symlink logic in deco-archive will result in failures with read-only /usr/share (%{_netsharedpath}).  The dir where deco looks for the scripts (ie. where they are symlinked in) would be better placed in /var/lib/deco.  The "source" script dir is fine in /usr/share/deco.

Hi Ville,
I wasn't very sure what to put for the license tag since no source file that contains code specifies a license in its header. There is only the LICENSE file that claims GPL3, even that file just mentions it in two lines and does not give the full text of GPL3.

I have seen in some reviews that whenever the source code files do not specify a specific version of GPL, a generic version (like GPL+ ot GPLv2+) was picked.

So do you think that whatever says in that LICENSE file, is enough to specify that the package is GPL3?

I'm doing the other changes you asked and update the packages soon. Thanks for the review.

I'm confident that GPLv3 would be the correct choice for this package.  GPL+ is correct when a package just includes the general GPL text (usually as COPYING) without being more specific anywhere else (because that's exactly what the GPL text says - any version of the GPL goes then).  GPLv2+ on the other hand should be chosen only when something in the package actually explicitly says it is "v2 or later".  The only mention of the license here is in the LICENSE file, and it is explicit about GPL v3.  It would not hurt to ping upstream to include the whole GPL v3 text in the package and license notices in source files though, but that's not a requirement for the package to pass review.

Alright, files updated:

SPEC: http://oget.fedorapeople.org/review/deco.spec
SRPM: http://oget.fedorapeople.org/review/deco-1.5.7-2.fc9.src.rpm

%changelog
- License is GPLv3.
- The extraction scripts will be inside %%{_var}/lib/%%{name}.


note: I updated deco-archive too, accordingly.

Approved.

New Package CVS Request
=======================
Package Name: deco
Short Description: Extractor for various archive file formats
Owners: oget
Branches: F-9 F-10
InitialCC:

cvs done.

deco-1.5.7-2.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/deco-1.5.7-2.fc10

deco-1.5.7-2.fc9.1 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/deco-1.5.7-2.fc9.1

deco-1.5.7-2.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update deco'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2008-10788

deco-1.5.7-2.fc9.1 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update deco'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-10877

deco-1.5.7-2.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

deco-1.5.7-2.fc9.1 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.