On Fri, 20 Feb 2004, Gavin Henry wrote:
I looked at your SPEC file and compared it what I had. I have the following differences:
- What is the reason for choosing noarch ?
I am a beginner with building rpms, so I am trying to do as many as possible.
I understand.
I thought, if it was noarch it would indicate it would work on any rpm distro.
Well, sadly RPM doesn't have a standard for saying for which distribution something was made. It would have been nice even if Red Hat would have added something more to the Distribution-tag than only 'Red Hat Linux' so that one could query rpmdb for those.
That's why some repositories are adding distrotags. In my opinion it's better to have 5 identical packages with a different package name (release) than to have one package that's uncertain for what distro it was packaged for (omitting the distrotag is difficult as you can't say it will work for any future distribution).
noarch packages is to indicate that a package works for any architecture. Mostly used for shell-scripts, some python/perl packages and other packages that don't contain architecture specific binaries.
- No desktop entry
- No desktop icon
I didn't notice there was any.
Well, even if there's no icon GUI programs should appear somewhere in the menu. If I have no icon I usually take the icon that Red Hat provides for the same Category so that it doesn't show up with a blank.
But putty was something that people mat recognize from the icon (when they move from Windows to Linux) so I thought it was important to have the same icon.
- No manpages (there are 2 missing since the last release though)
I need to check for these.
- You have a static version-less dependency for gtk+
Again, a beginner, so all this will be changed.
Well, actually if you wanted to create one package that worked for different Red Hat packages, this was the right way to do it. But I don't think it's better to tag a package for a specific distribution and then the requirement isn't really needed (and wrt managing the files unwanted).
- Don't use %makeinstall where possible
I understand this bit. You have: %makeinstall -C unix -f Makefile.gtk in your specfile.
Yes, since you didn't include the manpages, using %makefile would have forced you to include everything the developers wanted you to include.
It's always better to follow an existing infrastructure if you can. In a lot of case you can't though.
I know you are much better than most at doing rpms, so I will update mine to include a desktop entry, pic and man files. Also, take out gtk+ in requires and what is this for:
### FIXME: Disable missing pscp.1 and psftp.1. (Please fix upstream) %{__perl} -pi.orig -e ' s|-O2|%{optflags}|g; s|/usr/local|%{_prefix}|g; s|^(\t$(INSTALL_DATA) -m 644 ps.+)$|#$1|; ' unix/Makefile.gtk
Well, I favor perl-oneliners over patches as they allow me to quickly see what it does without having to look for other files and sometimes lots of data. They also stand a fair chance of working when you update to newer releases and can even be automated to test if a specific patch is still needed.
Of course sometimes a patch is absolutely required, but if it can be done inline I'd rather do it like that.
The first substitution replaces the normal compiler-flags to what RPM is normally using. The second replaces all instanced of /usr/local by the prefix that's defined by RPM, usually /usr. And the last substitution disables 2 manpages (comment above) that were rmeoved from the official release).
Is this built for servral version of gnome? Hence you if/else loops.
Yes, this is rather sad. RH73 and earlier don't have a desktop-file-install utilitiy which I use to install desktop-files. So that's why I first query for its existance and then use it if it exists.
Again, I am learning :-)
That's good ! ;)
Lastly, if I had known you had done one already, I wouldn't of done one :-)
But mine does a least work ;)
Well, it's definitely better to try yourself and then look at others (than just look at others). If you're goal is to learn to package, anyway.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]