New package: icmpdn

[Oliver Falk]

On 06/28/2005 08:55 PM, Fredrik Tolf wrote:
> I'll answer the remaining points from Oliver Falk further down.
> 
> On Tue, 2005-06-28 at 17:47 +0200, Michael Schwendt wrote:
> 
>>On Tue, 28 Jun 2005 16:22:11 +0200, Fredrik Tolf wrote:
>>
>>>>* Remove Vendor Tag
>>>
>>>I'm sure you're right, but what is there supposed to be instead? Surely,
>>>the author is supposed to mentioned so that people know who to
>>>blame? ;-)
>>
>>That's what documentation files are for. Upstream projects can put contact
>>information, bugzilla databases, e-mail addresses there. The vendor of
>>the package is the person/organisation who builds the binary packages.
>>At Fedora Extras, both Vendor and Packager tag are left empty in the
>>spec file. Vendor information could be filled in by the build system.
> 
> 
> That makes perfect sense. However, it would be kind of good to have them
> filled in when I build the packages that I put on the homepage as well.
> I did notice in the Wiki link that Ville Skyttä sent that I could do
> something a filed called ~/.rpmmacros for that. I googled around a bit
> for it, but could find nothing about that particular bit. Does anyone
> have a link with info on this?
> 
> Am I, by any chance, just supposed to put "%packager MyName" in there
> and be done with it?

Yes, you can add something like this. Eg.:
[oliver at moon ~]$ cat .rpmmacros | grep oliver
%_topdir	/home/oliver/RPMBuild
%packager       Oliver Falk <oliver at linux-kernel.at>

or whatever you like...

>>>>* Source is better written as Source0 and is missing the full URI to the 
>>>>tarball
>>>
>>>Again, I'm sure you're right, but what's the difference between Source
>>>and Source0?
>>
>>They are the same. Just like "Patch0" and "Patch" is the same. Don't worry
>>about such recommendations. You are free to ignore them. It's unimportant
>>spec file beautiness. Lobbying for using Source0 and Patch0 even if there
>>is only one source file and one patch has been a recent move by some
>>packagers.
> 
> Well, as long as it doesn't break anything to call it Source0 instead, I
> guess I can just as well make everyone happy. :)

I'm allways recommending Source0 instead of Source, since - as I 
allready noted - mach is buggy and doesn't understand it. It's not 
because *I* like it, but for compatibility reasons with other systems...

>>>fonts anyway), but is there anything wrong with using UTF-8 in
>>>specfiles?
>>
>>Spec files ought to be UTF-8 for consistency with system defaults.
> 
> 
> Well, of course I wasn't intending to make it Shift-JIS or KOI-8 or
> anything. ;-)
> I was just thinking whether it's OK to use non-ASCII characters. If it's
> OK, I certainly wasn't planning to do it with anything other than UTF-8.

I should have used a machine with proper UTF8 support, then I would not 
start this discussion. :-) If it's just UTF8, it's OK for me.

>>>>* In %build section, you should use %configure - it should set 
>>>>everything correctly
>>>
>>>As I mentioned, I don't know much about building RPMs, so you may well
>>>be right, but does this "%configure" set the libdir correctly to /lib?
>>>AFAIK, that's pretty important for NSS modules.
>>
>>You can override %configure's defaults like this:
>>
>>  %configure --libdir=%{_lib}
>>[...]
>>Typo. Make it:
>>
>>    %configure --libdir=/%{_lib}
>>
>>Note that on 64-bit multilib systems, the NSS modules are located
>>in /lib64, not /lib.

Yes, Axel use the configure from above. And in %files use /%{_lib}. I 
guess it's not a must have, that those libs are available at boot time 
(before /usr get's be mounted), but let's do it this way.

> Does that mean that %{_lib} expands to only lib or lib64, and
> not /usr/lib or anything of the kind?

Yes, that's exactly how it works.

>>>>* make is better written as: make %{?_smp_mflags}
>>>
>>>OK, will fix.
>>
>>And be aware of SMP make flags breaking sometimes. ;)
>>
>>Adding smp_mflags would be something a packager would documented in the
>>spec %changelog, so when a new tarball fails in "make" in weird ways, the
>>changelog entry would help when looking for the possible culprit.

I tried building it on an smp system with smp_mflags and it worked, but 
it might be a good idea to add a note to the changelog.

> Well, now that I know what the %changelog section is, I'll do that. Is
> there any particular formatting that you prefer the %changelog section
> to comply to? Right now, I wrote in the kind of formatting that Emacs'
> VC mode generates with C-x v a.

Changelog should have the following format:
* [date] [person name] [<person email>]     - [version]-[release]
- [ What i did, multiple lines are
   allowed]
- [ And what I did as well]

Example:
* Wed Jun 29 2005 Oliver Falk <oliver at linux-kernel.at>	- 1.0.0-1
- I wrote an example changelog entry and posted it to the
   fedora-extras-list

>>>>* In %install section do only use rm -rf "$RPM_BUILD_ROOT" (same for the 
>>>>%clean section)
>>>
>>>Again, I'm sure you're right, but it seems weird to me not to check so
>>>that the root dir doesn't get removed. Will fix, though. You are
>>>referring to just removing the checks, right?
>>
>>See yesterday's/today's thread about the "fish" package. Please don't
>>decrease readability of your spec file with insane checks which are
>>advertised as adding security. They don't add any real security. And btw,
>>I doubt you have ever before seen somebody building rpms as root with an
>>explicit build-root set to /. Let's get rid of such checks, please.
> 
> I didn't even know that it was possible to build RPMs not being root.

See the macro (from my cat .rpmmacros) %_topdir. You must create a few 
directories (in %_topdir} manually and then you are done:
mkdir -p BUILD RPMS/{i386,i686,noarch,athlon} SOURCES SPECS SRPMS

You can also add other arch-dirs (eg. athlon, i586) and so on. It 
depends on what machine you are and for what arches you are going to 
build rpms for.

> That was very good to know. If you don't mind me asking, though: Why is
> that rm -rf command there at all? Isn't that the kind of thing that
> rpmbuild ought to take care of itself?

No, that's up to the specfile. There are multiple reasons for that, that 
I don't want to describe in detail now...

>>>>* %post and %postun should run ldconfig
>>>>   And therefor PreReq: /sbin/ldconfig
>>>
>>>Would fix, but I have no idea what "PreReq" refers to. Also, are you
>>>sure that running ldconfig really is necessary?
>>
>>Well, it's the command that refreshes the run-time dynamic linking
>>loader's cache. The libs in %_lib and %_libdir are found without running
>>it. But you want to update the cache.
>>[...]
>>dlopen accesses the same mechanisms.
> 
> Well, I knew what ldconfig was for, but I didn't think that dlopen uses
> it. Would fix it, but I still don't know what this "PreReq" thingie is.
> Is it a tag in the same sense as Source0?

Let the PreReq and the ldconfig stuff. rpm should check that 
automatically...

>>>>* In %files section icmpdnd is missing %attr to be sure the files are 
>>>>executable
>>>>* In %files section, init.d/ipcmpdnd is missing %config
>>>
>>>Will fix.
>>
>>Explicit %attr is redundant if the file was installed into build
>>root with proper permissions, which don't interfere with the %defattr
>>default attributes.

If the install does it correctly, it's OK to let it be...

[ ... ]

Best,
  Oliver