Bug 987738 - Review Request: dput - Debian package upload tool
Review Request: dput - Debian package upload tool
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: František Dvořák
Fedora Extras Quality Assurance
:
: 1063075 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-23 23:43 EDT by Christopher Meng
Modified: 2015-09-16 22:24 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-04 00:45:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Christopher Meng 2013-07-23 23:43:28 EDT
Spec URL: http://cicku.me/dput.spec
SRPM URL: http://cicku.me/dput-0.9.6.4-1.fc20.src.rpm
Description: This is the debian package upload tool, or dput. dput has been developed
because dupload, the only tool for doing uploads, has quite
a few open bug reports and the code is in my opinion not very clean.

Fedora Account System Username: cicku
Comment 1 Ed Santiago 2013-07-30 13:23:33 EDT
1. Should /etc/bash_completion.d/dput be marked %config? It really isn't one, and no other bash_completion.d files are marked as such on my F19 box:

   for i in /etc/bash_completion.d/*;do printf "%02x %s\n" $(rpm -q --qf "%{fileflags}\n" -f $i) $i;done|grep -v ^00

2. Trivial consistency nit: 'install ... dput' has a trailing slash in the destination dir; no other install has a trailing slash.

3. The mkdirs ... are they necessary? Review guidelines state that "A package must own all directories that it creates". I think it's safe to remove everything except the two %{_datadir/%{name} ones, because the rest are owned by the filesystem package. (Even bash_completion.d, despite the messy rpm -qif /etc/bash_completion.d|grep ^Name).
Comment 2 Christopher Meng 2013-07-31 01:45:59 EDT
1. If I don't mark it as %config I'm afraid rpmlint will shout. But it's right to not mark them as they are not conf files. I remember someone has marked it as %config, or maybe I forget, whatever.

2. Fixed.

For issue 3, you can review my spec again:

Spec URL: http://cicku.me/dput.spec
SRPM URL: http://cicku.me/dput-0.9.6.4-2.fc20.src.rpm

Not sure if you are packager now, if you get approved later, please continue.
Comment 3 Christopher Meng 2013-07-31 01:45:59 EDT
1. If I don't mark it as %config I'm afraid rpmlint will shout. But it's right to not mark them as they are not conf files. I remember someone has marked it as %config, or maybe I forget, whatever.

2. Fixed.

For issue 3, you can review my spec again:

Spec URL: http://cicku.me/dput.spec
SRPM URL: http://cicku.me/dput-0.9.6.4-2.fc20.src.rpm

Not sure if you are packager now, if you get approved later, please continue.
Comment 4 Ed Santiago 2013-08-01 17:27:12 EDT
[ disclaimer#1: I'm not a packager yet; I'm just trying to learn the ropes ]
[ disclaimer#2: total n00b, so my interpretation of the guidelines may be off ]

That said...

1. Thanks for removing the %config. I'm pretty sure that's the right thing to do, and the rpmlint non-conffile-in-etc warning is ignorable.

2. Thanks.

3. I'm sorry, I was totally, embarrassedly confused about directory ownership. Your original mkdirs were in fact fine, and probably preferable to the mix of -D in some but not all install commands. Again, I'm really sorry for my confusion. But:

4. You removed the gzip actions, and changed the man page install commands to write .gz files. I do not think that does what you think it does. (As in: yes, the files are named .gz, but they are not actually gzip'ed).

Also, your -2 srpm seems to be corrupt (cpio: premature end of file). The sha1sum of my download is f33fce1a2cb4faab5504cc663649ca0ed0f4e63c.
Comment 5 Christopher Meng 2013-08-04 23:39:08 EDT
(In reply to Ed Santiago from comment #4)

Oh I forgot to cleanup my brain ;)

Manpage should be installed to destdit mandir/man1 with install.

Then RPM will automatically gzip them.

Fixed.


Spec URL: http://cicku.me/dput.spec
SRPM URL: http://cicku.me/dput-0.9.6.4-3.fc20.src.rpm
Comment 6 František Dvořák 2013-11-30 09:44:35 EST
My observations:

1) description could be improved

Inspiration can be found in upstream: http://anonscm.debian.org/gitweb/?p=collab-maint/dput.git;a=blob;f=debian/control;hb=HEAD .


2) license: there are "and above" in copyright notices, I think it should be GPLv2+


3) incorrect FSF address in /usr/bin/dput and /usr/bin/dcut, upstream should be notified


4) missing build requires python2-devel or python3-devel

Here it is not so clear, what to do with it.

There are *.py and *.pyc files in /usr/share/dput/, and this directory doesn't distinguish the python version. Proper directory could be %{python_sitelib} or %{python3_sitelib}, but these files are used as "plugins" and the code expects them in /usr/share/dput. Am I right these files should remain there? (I'm not python programmer.)

I that case it could be just used python-devel as the build dependency (= using default python BR).
Comment 7 Christopher Meng 2013-12-02 05:33:55 EST
(In reply to František Dvořák from comment #6)
> My observations:
> 
> 1) description could be improved
> 
> Inspiration can be found in upstream:
> http://anonscm.debian.org/gitweb/?p=collab-maint/dput.git;a=blob;f=debian/
> control;hb=HEAD .

Thanks, anonscm sometimes can't be accessed. I will change the description later.

> 4) missing build requires python2-devel or python3-devel
> 
> Here it is not so clear, what to do with it.
> 
> There are *.py and *.pyc files in /usr/share/dput/, and this directory
> doesn't distinguish the python version. Proper directory could be
> %{python_sitelib} or %{python3_sitelib}, but these files are used as
> "plugins" and the code expects them in /usr/share/dput. Am I right these
> files should remain there? (I'm not python programmer.)
> 
> I that case it could be just used python-devel as the build dependency (=
> using default python BR).

Well, I don't think this is a problem. This is not a python module, can't be used in system-wide, so we don't need to store it under python_sitelib, see my another package "git-cola".

Do you want to review it? ;)
Comment 8 František Dvořák 2013-12-02 07:27:41 EST
Yes, I can review it. :-)

Do you plan to push it to EPEL? I can imagine dput could be useful also there (RHEL or RHEL-based server working with Debian packages...).
Comment 9 Christopher Meng 2013-12-09 03:28:37 EST
(In reply to František Dvořák from comment #8)
> Yes, I can review it. :-)
> 
> Do you plan to push it to EPEL? I can imagine dput could be useful also
> there (RHEL or RHEL-based server working with Debian packages...).

Sure, why not ;)

I only don't include support for EL5 of all my packages.
Comment 10 František Dvořák 2013-12-13 08:35:43 EST
Yes, EL6 is OK. It should not need the modifications. Waiting for the new version. :-) -- František
Comment 11 Christopher Meng 2014-01-03 13:21:31 EST
(In reply to František Dvořák from comment #10)
> Yes, EL6 is OK. It should not need the modifications. Waiting for the new
> version. :-) -- František

Uh...New version? N-2 was released 1.5 years ago, N-1 released 0.5 years ago, awaiting what?
Comment 12 František Dvořák 2014-01-03 16:51:47 EST
No, I just mean the new specfile/srpm, addressing the issues in comment #6.
Comment 13 Christopher Meng 2014-01-04 00:45:22 EST
(In reply to František Dvořák from comment #12)
> No, I just mean the new specfile/srpm, addressing the issues in comment #6.

Sorry, after a moment's indecision, I decide to close this bug and package dput-ng to replace this old tool.

Please review that one when I'm ready ;)

Ref: http://dput-ng.debian.net/
Comment 14 Christopher Meng 2014-02-09 19:57:49 EST
*** Bug 1063075 has been marked as a duplicate of this bug. ***

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