PuTTY 0.54 rpms (http://www.chiark.greenend.org.uk/~sgtatham/putty/)

[Dag Wieers]

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 at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]