[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: New package: icmpdn



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 moon ~]$ cat .rpmmacros | grep oliver %_topdir /home/oliver/RPMBuild %packager Oliver Falk <oliver 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 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]