Spec URL: http://people.midymidy.com/~ekd123/RPM/lunar-date.spec SRPM URL: http://people.midymidy.com/~ekd123/RPM/lunar-date-2.4.0-1.fc19.src.rpm Description: A feature-complete GLib-based library for Chinese lunar date conversion. Fedora Account System Username: unixekd123
1.This is not the latest version. 2. Have you tested its usability? This package has been packaged by myself for a long time, but because its upstream is dead, I'm not sure if it's useful.
(In reply to Christopher Meng from comment #1) > 1.This is not the latest version. http://code.google.com/p/liblunar/ shows that this is the latest one. > > 2. Have you tested its usability? This package has been packaged by myself > for a long time, but because its upstream is dead, I'm not sure if it's > useful. https://extensions.gnome.org/extension/675/lunar-calendar/ depends on it.
I can find 3.0 version.
Nope, that's lunar-calendar, a graphical library targetting Gtk+3, while lunar-date is a low-level library for date conversion.
Have rpmlint and/or "fedora-review -b 995995" been run for this one yet? > %files data > %dir %{_datadir}/liblunar > %{_datadir}/liblunar/* %files data %{_datadir}/liblunar/ would be shorter and achieves the same. Btw, here the subpackage includes only three tiny files, each below 1KB, and the base package even strictly depends on this package. Is that really enough reason to introduce a noarch subpackage? > %package docs The guidelines recommend -doc not -docs: https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation The subpackage is 14788 bytes long. I would keep it in the -devel package.