[Bug 1292209] Review Request: python-nsdf - Support library for the Neuroscience Simulation Data Format

bugzilla at redhat.com bugzilla at redhat.com
Thu Jan 7 22:53:36 UTC 2016


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



--- Comment #9 from Zbigniew Jędrzejewski-Szmek <zbyszek at in.waw.pl> ---
(In reply to Paul Belanger from comment #8)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #7)
> > (In reply to Paul Belanger from comment #6)
> > > [!]: License file installed when any subpackage combination is installed.
> > >    devel and tools are missing the LICENSE
> > Different package? This one only has python2-nsdf and python-nsdf-doc
> > subpackages,
> > and both have the README, although they don't have a LICENSE file, because
> > on is missing from the upstream repo and tarball.
> > 
> > You could (and should) say instead, that I'm supposed to contact upstream
> > about
> > adding a license file. Indeed, I haven't done this.
> > 
> Right, I had noticed the LICENSE was not installed in the files sections.  I
> should have been more detailed about notifying you about that.

I contacted upstream about adding a license:
https://github.com/nsdf/nsdf/pull/41.

> > > [ ]: Package contains no bundled libraries without FPC exception.
> > > [x]: Changelog in prescribed format.
> > > [ ]: Sources contain only permissible code or content.
> > > [-]: Package contains desktop file if it is a GUI application.
> > > [x]: Development files must be in a -devel package
> > > [x]: Package uses nothing in %doc for runtime.
> > > [!]: Package consistently uses macros (instead of hard-coded directory
> > >      names).
> > Can you be more specific here?
> > 
> Doh, I missed my comment at the top.  For this, I was looking at other
> reviews an noticed the nsdf name seemed copied over the entire spec file, vs
> setting up a macro for %{pypi_name} or %{srcname}.

Note that the guideline is about "hard-coded *directory* names". Directory
names indeed can change and vary between architectures, and are long, so using
macros makes sense. Similarly for version and other things which are updated
regularly. But the package name is unlikely to *ever* change, so using a macro
doesn't buy anything. In fact I find %{pypi_name} or %{srcname} much less
readable than the package name.

(On a similar note: people sometime use %{__make} instead of just make, and
simalar macros for other basic commands. I think it's pointless, because
make's name is never going to change, and/or if somebody can insert a different
make in $PATH, they can just as well insert any other command called from
the Makefile, so there's no reason to single out make just because it is called
directly. So again, using macros for *files* is again a waste of keystrokes
(as opposed to directory names).)

> > What about all the open boxes [ ]?
> 
> Thanks for the feedback, I admit I should have likely removed the open boxes
> lines. I wasn't comfortable filling some of them in.
> 
> Moving forward, I'll do my best to leave more detail, then less for reviews.

Cool.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component


More information about the package-review mailing list