Hi Gavin, On Thu, 19 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 ? + No desktop entry + No desktop icon + No manpages (there are 2 missing since the last release though) + You have a static version-less dependency for gtk+ + Don't use %makeinstall where possible You can compare it with: http://dag.wieers.com/packages/putty/putty.spec For those interested for RHEL21, RH73, RH80, RH90, RHEL3 and RHFC1 at: http://dag.wieers.com/packages/putty/ Kind regards, -- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 20 February 2004 00:10, Dag Wieers wrote: Cheers Dag, I will look over this and reply later today. - -- Kind Regards, Gavin Henry. Director. Open Source. Open Solutions. http://www.suretecsystems.com

On Fri, 20 Feb 2004, Gavin Henry wrote: I understand. 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. 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. 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). 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. 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). 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. That's good ! ;) 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(a)wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]

On Fri, 20 Feb 2004, Gavin Henry wrote: "noarch" means "no architecture" or rather "architecture independant", which means that the contents of the package are useable as-is on x86, AMD64, ia64, alpha, sparc, ppc, ppc64, etc. without modification. Examples of noarch packages are documentation, fonts, other packages which are strictly architecture independant data, packages containing only interpreted perl, python, shell scripts, etc. Any package which contains code compiled specificially for a given architecture, such as i386, must not be flagged as "noarch", as rpm will allow it to be installed on any architecture then, which will result in failure at runtime. Make sure rpm is configured to refuse to generate packages if any files have been installed in the buildroot which are not listed in the %files section. That is the default if you install redhat-rpm-config. Hope this helps. Take care! TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat

Gavin Henry wrote: Well given the definition that creates it in /usr/lib/rpm/macros is: %debug_package \ %ifnarch noarch\ %global __debug_package 1\ %package debug\ Summary: Debug information for package %{name}\ Group: Development/Debug\ AutoReqProv: 0\ %description debug\ This package provides debug information for package %{name}.\ Debug information is useful when developing applications that use this\ package or when debugging this package.\ %files debug -f debugfiles.list\ %defattr(-,root,root)\ %endif\ %{nil} Putting: %debug_package %{nil} .. in your $HOME/.rpmmacros file is one way is it not? Carwyn