-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 andreas.hanke@gmx-topmail.de wrote:
are there any generic packaging "style" guidelines for SUSE Linux packages?
Not much. http://forgeftp.novell.com//library/SUSE%20Package%20Conventions/spc.html
More precisely, I have the following questions: - Is %buildroot preferred over $RPM_BUILD_ROOT?
As you prefer, it doesn't make any difference Personally, I always use %{buildroot} because it very clearly makes the differences between shell variables and stuff coming from rpmbuild. But it's really a matter of personal preference.
The environment variable is the documented thing. The same is the case with %optflags vs. $RPM_OPT_FLAGS IIRC.
Same thing, they're exactly the same. Again, personally, I prefer %{optflags} for the same reason as above.
- Is %configure preferred over ./configure? IIRC until recently, no package in the distro used it and everything worked well without it.
IMO you should really consider using %configure, as it will pass all the necessary flags that are common to every autoconf project, and you don't need to do it yourself. Note that many (dare I say "most" ?) SUSE spec files don't comply with their own guidelines ;)
I'm asking that because %configure IMHO sucks terribly. It sets questionable values for --libexecdir, --localstatedir and --sharedstatedir for packages whose prefix is /usr, requires even more macros to be redefined for packages whose prefix is not /usr (/opt/kde3, /opt/gnome and /usr/X11R6 come to mind) and always sets --libdir to %{_prefix}/%{_lib} although it must remain %{_prefix}/lib for some packages.
Sorry, but I totally disagree here. All I set is %define _prefix /usr (and even that is optional, I rather to so for deterministic reasons) All the rest is computed properly and is always correct. Exceptions: 1) KDE For KDE you should not use %configure but unsermake instead: %define _prefix /opt/kde3 %define _sysconfdir /etc/opt/kde3 ... %build . /etc/opt/kde3/common_options update_admin ./configure $configkde make %{?jobs:-j%{jobs}} # note: "make" and not "%__make" when using unsermake ! %install %makeinstall 2) GNOME %define _prefix /opt/gnome %define _sysconfdir /etc/opt/gnome %build export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 %configure \ --disable-schemas-install %__make %{?jobs:-j%{jobs}} %install export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 %makeinstall I only very, very rarely encountered packages that must install into %{_prefix}/lib instead of %{_libdir} (= %{_prefix}/%{_lib}). When that happens, nothing easier than %define _prefix /usr %define _libdir %{_prefix}/lib ... %build %configure ... I don't see the problem with that. (and of course, perl and python packages are totally different)
So what's the exact benefit of %configure? It makes some autoconf calls shorter by adding the right options and others longer by adding wrong ones, which have to be corrected manually, so we end up adding options manually in either case.
What wrong ones ? I never, ever had to "fix" those options. And I currently maintain 700 packages.
- %optflags / $RPM_OPT_FLAGS again: Are they "nice to have" things or is not using them a bug that should be reported?
You *MUST* use them, always. Also check that they are actually passed to the compiler (especially when you don't have autotools but just some Makefiles) That is particularely true for SUSE 10.0 and 10.1, as %{optflags} includes -D_FORTIFY_SOURCE which adds some more security using glibc checks for things like memcpy, strcpy, ... (the usual suspects).
- run-time and -devel packages
Is there a general rule for splitting or not splitting library packages into run-time and -devel subpackages? Is this decided according to the size of a library, the number of header files, other criteria?
No, unfortunately there's no rule. I'm for *always* splitting. At least that makes it very clear, and is an easy convention to go with. I think that's currently where the SUSE packagers are heading to. (correct me if I'm wrong)
I'm asking that because IMHO always splitting them is an interesting approach even for tiny packages as it allows third party people to package another version of the same library that has a different SONAME without having to worry about conflicts. The -devel packages would still be clashing in most of such cases, but the run-time packages can be installed in parallel.
100% ACK.
And always splitting is an easy rule, no need to consider subjective
criteria like the size or the number of files. Just always do, period.
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\