Spec and SRPM from: http://people.redhat.com/caillon/RPMS/rawhide/banshee/ Description: libipoddevice provides device-level support for Apple's iPods. libipoddevice is written in GObject/C.
One minor nit, which gets exposed when trying to build this package on FC4: ... error: Package requirements (gobject-2.0 glib-2.0 dbus-1 dbus-glib-1 hal >= 0.5.2 libgtop-2.0 >= 2.12.0) were not met: Requested 'libgtop-2.0 >= 2.12.0' but version of libgtop is 2.10.1 => Missing "BuildRequires: libgtop-devel >= 2.12.0"
MD5Sums: 000b3c7b82026bf052a16811ba34c515 libipoddevice-0.4.1.tar.gz Good: * Upstream source tarball verified * Package name conforms to the Fedora Naming Guidelines * Group Tag is from the official list * Buildroot has all required elements * All paths begin with macros * All necessary BuildRequires listed. * Package builds in Mock. * Package installs and uninstalls cleanly on FC5. * Make succeeds even when %{_smp_mflags} is defined * Rpmlint does not find problems Needs Work: * Source URL isn't canonical. Should be http://banshee-project.org/files/%{name}/%{name}-%{version}.tar.gz * Refer to Comment #1, if planning to release for FC4. * License is LGPL, not GPL. * Add COPYING file to package. Once these items are fixed, consider it approved.
(In reply to comment #2) > * Source URL isn't canonical. Should be > http://banshee-project.org/files/%{name}/%{name}-%{version}.tar.gz Don't use %{name}, %{version}, etc. in the pathname, only in the filename.
(In reply to comment #3) > Don't use %{name}, %{version}, etc. in the pathname, only in the filename. Why, has something changed recently in the wiki?
It's never actually been put into the wiki, but that's been an unwritten rule for as long as I can remember.
(In reply to comment #5) > It's never actually been put into the wiki, but that's been an unwritten rule > for as long as I can remember. Really? I've been doing packages since back in the fedora.us days, and I'm not familar with that.
(In reply to comment #6) > (In reply to comment #5) > > It's never actually been put into the wiki, but that's been an unwritten rule > > for as long as I can remember. > > Really? I've been doing packages since back in the fedora.us days, and I'm not > familar with that. Neither am I nor do I agree with Ignacio.
(In reply to comment #5) > It's never actually been put into the wiki, but that's been an unwritten rule > for as long as I can remember. Actually it's never actually been into the wiki because the proponents of this rule never managed to convince other packagers. So 1. today it's not mandatory 2. I very much doubt it would be accepted if someone tried to make it mandatory
Well, it's been a recommendation at fedora.us, and many packagers have been so nice and accepted it. Its background is that (1) packagers would simply copy URLs into the .spec file, making sure the download location from within their browser/downloader really matches the spec file (2) reviewers could copy the URL during review and would not need to use spectool or other forms of expanding the macros and retrieving a valid URL -- remember that reviewers also need to verify download locations, so visiting web pages, looking up download sections and comparing the URLs with spec files With macros in download URLs, what often happens is that packagers don't verify them, not even when a tarball changes from .tar.gz to .tar.bz2 and moves to a different directory. In that case they simply change the file extension to make the src.rpm work again. ;)
(In reply to comment #9) > Well, it's been a recommendation at fedora.us, and many packagers > have been so nice and accepted it. Need I remind you fedora.us pushed epochs everywhere? fedora.us rules can and have been revisited, I fact I distinctly remember this specific issue being discussed on fedora-extras or fedora-maintainers, and as a result of the discussion it was NOT added to FE packaging rules
I don't understand what you're trying to point out, I'm afraid. There's a big difference between guidelines and policies. Explicit Epoch 0 was a necessity and a completely different topic, btw.
Okay, this discussion should go elsewhere. I didn't use any macros for directories, mainly out of personal preference. Module successfully imported into extras.
Some recommendations for you spec file: * Using %configure --disable-static and removing the "%exclude *.a" would speed up compilation by almost factor 2 * %configure --disable-dependency-tracking would further speed up building. * I'd use make DESTDIR=${RPM_BUILD_ROOT) install instead of %makeinstall (This avoids breaking libtool archives for some versions of libtool ;) )