-----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/ /\\ _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEa5rar3NMWliFcXcRAoqCAKC4Hc8fWGW8b9jH0L0Jl/57lpQyqQCeO8Hg o85hdvj/FsSWcw1BwT6ssks= =OTwk -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 andreas.hanke@gmx-topmail.de wrote:

...

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.

The problem here is two-fold: a) In many cases the standard autoconf defaults are already correct, b) In other cases, the line %configure expands to is not correct.

Actually, in my experience, many packages have wrong autoconf defaults, especially wrt libdir that's hardcoded to ${prefix}/lib instead of detecting a biarch platform and using lib64 where appropriate. If I wasn't using %configure, I would always pass --libdir=%{_libdir} anyway, to make sure (and it wouldn't harm either, even if it wasn't necessary)

And: c) Having to add the required options manually is not necessarily a bad thing, as it can prevent some common mistakes. And it can help tracking which degree of customization is actually really needed in a package.

I do that by setting %_libdir, %_localstatedir, %_sysconfdir when necessary, but apply them with %configure.

...

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.

I couldn't disagree more. This would be nice if it were the case, but it isn't. Not always, actually not even in most cases and the worst problem about it is that people think it computes things correctly although it doesn't. If it's even possible to call it a computation what %configure does, it's a very, very simple one, to say the least.

In detail. A simplified excerpt of what %configure becomes: ...

I know. Sure, it's very simple, it just passes all common autoconf flags to configure, no black magic here. No one ever said it takes any work from the packager, except that you type a lot less ;) But my experience is the exact opposite - you say "actually not even in most cases"... ? I can't remember a single spec file where I had to use ./configure instead of %configure (except, of course, when configure is not an autoconf script ;)) - besides KDE packages that work with unsermake, as already mentioned in my previous mail. ...

--prefix=%{_prefix}: OK, nothing to worry about. Will be redefined if necessary.

Right.

--exec-prefix=%{_exec_prefix}: Unncessary, already defaults correctly to %{_prefix}. Different values for %{_prefix} and %{_exec_prefix} are never used. --bindir=%{_bindir}: OK, nothing to worry about, but completely unnessary to specify. --sbindir=%{_sbindir}: OK, nothing to worry about, but completely unnessary to specify.

Does it harm to specify them explicitely ? it doesn't.

--sysconfdir=%{_sysconfdir}: Dangerous! Defaults to /etc, correct for most packages whose %{_prefix} is / or /usr, but not all. Almost always wrong for packages whose %{_prefix} is neither / nor /usr, with some interesting exceptions.

Well, if it isn't /etc, then override with %define _sysconfdir ... I always do that at the top of the spec file, which directly shows that the package has some slightly unusual behavior.

--datadir=%{_datadir}: OK, nothing to worry about, but completely unnessary to specify. --includedir=%{_includedir}: A reasonable default, no need to specify explicitly.

Doesn't harm either.

--libdir=%{_libdir}: OK for the majority of packages, but wrong for some exceptions.

As written above, my experience is the opposite: the defaults are wrong for at least 20% of tarballs. Specifying --libdir=%{_libdir} is not wrong. Not changing %_libdir to %{_prefix}/lib is wrong (for some packages, that is).

--libexecdir=%{_libexecdir}: Always wrong. Must be redefined, highly dependant on the package. Candidates are:

%{_prefix}/lib/%{name} %{_prefix}/lib %{_sbindir} %{_libdir}/%{name} (very rarely, indicates a bug in the package) %{_libdir} (very rarely, indicates a bug in the package)

${libexecdir} is rarely used actually. At least 95% of packages install stuff into ${libdir}, but not ${libexecdir} And again, if %{_prefix}/libexecdir is not the correct place for a package that installs files there, %define _libexecdir ...

--localstatedir=%{_localstatedir}: Defaults to /var. Always wrong! Candidates are: /var/lib/%{name} /var/lib /var%{_prefix}/%{name} /var%{_prefix} /var/cache/%{name} /var/cache

I disagree here. Every package I know of that installs files or hardwires some directory (usually it's -D into the binaries, for log files or similar) actually uses ${localstatedir} as a *prefix* They use ${localstatedir}/log or ${localstatedir}/lib/foo, and only expect ${localstatedir} to give them /var

--sharedstatedir=%{_sharedstatedir}: Defaults to /var/com. Always wrong! Candidates are the same as for --localstatedir.

Never seen a package that uses that.

--mandir=%{_mandir}: Correct for packages whose %{_prefix} is either /usr or /opt/gnome, but wrong for all others, especially / and /usr/X11R6.

Also depends on the SUSE version. AFAICR, older versions had GNOME manpages installed into /opt/gnome/man and not /opt/gnome/share/man (same for KDE). Still, I don't see the problem. A lot of source tarballs use ${prefix}/man to install manpages into (I'd say at least 30%), so what's wrong with always specifying --mandir=%{_mandir} ? You are absolutely right with the exceptions (indeed, most notably /usr/X11R6), but just do: %define _prefix /usr/X11R6 %define _mandir %{_prefix}/man and then use %configure When you do it that way, you can also use the path placeholder macros in the %files sections (and there's a single place where to change %_mandir, no need to change anything else in the spec file).

--infodir=%{_infodir}: Same as --mandir.

Right.

And now I really fail to see the advantage of %configure, given the fact that it expands to a line which is partly correct and helpful, partly correct and unnecessary and partly inherently wrong because there's no way to guess the "right thing" automatically. This includes especially --libexecdir, --localstatedir and --sharedstatedir. They are not guessed correctly by default and I have no idea how to improve the guessing in a generic way.

As said, --localstatedir=%{_localstatedir} is correctly set to /var by %configure in almost every case I know of because it's being used as a prefix for log files and such. - --sharedstatedir is never used. - --libexecdir is rarely used. So, %configure does the right thing for all but --sharedstatedir and - --libexecdir where you almost always have to override %_sharedstatedir and %_libexecdir, and most often does the right thing for - --localstatedir (at least in my experience), and for the rest, it's almost always correct (sometimes %_sysconfdir and/or %_mandir/%_infodir have to be changed). I have a different point of view. %configure is always correct, because it just passes all common configure flags. When the *values* it passes are not correct, then adjust them with e.g. %define _libdir %{_prefix}/lib %define _mandir %{_prefix}/man What wrong with that ? Passing all configure flags is more deterministic IMO. Did you ever hard a package that didn't build because you explicitly specified one of those flags to configure ? I didn't.

To summarize, %configure looks to me like a typical example of "bloat" which is used just because it exists: It tries to make things easier, but actually makes a lot of things more complex. Redefining the macros which are wrong by default doesn't make anything more readable, IMHO it actually makes things more cryptic than an explicit ./configure invocation.

I don't agree, because you would have to redefine the macros anyway, in order to use them in the %files sections (and possibly in some scripting in the %install section). What you suggest is ./configure \ --prefix=%{_prefix} \ --libdir=%{_prefix}/lib \ --mandir=%{_prefix}/man ... %install ... %if %suse_version < 930 %__strip "%{buildroot}%{_prefix}/lib"/* %endif %files ... %{_prefix}/lib/libmoo.so ... %{_prefix}/man/man1/moo.1* When you modify the path placeholders - btw, that doesn't imply you would have to use %configure - you can refer to them everywhere: %define _libdir %{_prefix}/lib %define _mandir %{_prefix}/man ... %configure # or this way: CFLAGS="%{optflags}" CXXFLAGS="%{optflags}" \ ./configure --prefix="%{_prefix}" \ --libdir="%{_libdir}" \ --mandir="%{_mandir}" ... %install %if %suse_version < 930 %__strip "%{buildroot}%{_libdir}"/* %endif %files ... %{_libdir}/libmoo.so ... %{_mandir}/man1/moo.1* The second approach looks better to me (%configure also sets CFLAGS/CXXFLAGS/... to %{optflags}, which is mandatory) Using %configure or not, in this case, is probably a matter of preference, but still, %configure doesn't do anything wrong, it just passes all common configure flags. The values of the placeholders might be wrong, depending on the package. Either you "fix" them once by changing the placeholder, or you "fix" them several times by explicitly mentioning the idiosyncrasies of the package in %build, %install and %files

Sometimes it can be dangerous because packagers might think that %configure automagically does the "right thing" for them even if it

I don't think so. Sorry, I personally don't see that as a problem. Packaging is a very advanced topic for experienced users anyway. Will using ./configure instead of %configure save you from having to find out and specify the correct paths in the first place ? It won't either. The difference is just as of whether you specify them by changing the %_* placeholders or if you pass them to ./configure and refer to them in the %files section as well (at the very least).

doesn't, and as a user, it's more difficult for me to follow where the package differs from what I would get by running "./configure ; make ; make install" myself.

I don't see that happening either. As you wrote yourself, %configure doesn't do any black magic, it just passes all common configure flags. As a packager, you should know what they're being set to (it's not really difficult ;)). OTOH, I personally find referring to "%{_prefix}/lib" or even "/usr/lib" (as I see frequently in SUSE spec files) much, much worse. Overriding %_libdir once, in a single place in the spec file (IMO, the top of the spec file being the best and most visible place) and always referring to %_libdir is much cleaner, easier and more consistent (of course, same goes for other path placeholder macros).

...

1) KDE For KDE you should not use %configure but unsermake instead:

Yes, this is clear. And it shows nicely the difference between KDE and most other projects: All KDE packages use exactly the same set of options, so a macro would make sense here, but other packages are less streamlined and might need special attention.

Yes, there are some exceptions. I'd say 10% of KDE packages don't build properly when using unsermake, unfortunately. Mostly rather bad coded stuff on kde-apps.org But they do work with the usual %configure (or ./configure) && %__make && %makeinstall Drawback of not using unsermake (. /etc/opt/kde3/common_options ; update_admin ; ./configure $configkde) is that you also have to pass - --with-qt-dir explicitly in most cases. When that happens, I do it like this: %define _prefix /opt/kde3 %define _sysconfdir /etc/opt/kde3 %define qtdir /usr/lib/qt3 ... %configure --with-qt-dir="%{qtdir}"

...

# note: "make" and not "%__make" when using unsermake !

See, this is such an example where macros make things more cryptic, not easier. %{__make} expands to /usr/bin/make, but doesn't help here, and actually helps nowhere. Why not always use make directly? %{__make} would be useful if it included the -j flags automatically, but even then it would be dangerous because -j flags actually break some packages. If it's just /usr/bin/make, what's the benefit, that it looks more RPMish, that it doesn't let you override the make binary with another one in the PATH, something else?

Yes. On other operating systems (e.g. AIX, Solaris), you'd have to use "gmake" instead of "make", and overriding %__make in rpmmacros would be enough to have all spec files build correctly. That's just what those %__* macros are made for. Instead of presuming that it's always 'sed', 'rm', 'make', 'gcc', use the %__* macros so that you can possibly override them to suit your platform or setup in an rpmmacros file. (you might find that scenario highly hypothetical, but we use RPM at work to build packages on AIX, Solaris and HPUX) And as far as the -j flag in concerned, indeed, you can't always pass it in %__make, as it's sometimes (maybe 5-10%) breaks the build. Note that using %jobs is "the SUSE way" (or at least some de-facto standard on SUSE, I don't think it's explicitly specified somewhere), other distros use different placeholders - most notably, Fedora packagers uses %_smpflags SUSE: %__make %{?jobs:-j%{jobs}} FC : %__make %{?_smpflags:%{_smpflags}}

...

2) GNOME %define _prefix /opt/gnome %define _sysconfdir /etc/opt/gnome

Yes, often. And then, there are the exceptions. Like yumex, it lives in /opt/gnome, but still needs --sysconfdir=/etc because otherwise it doesn't find yum's config files. An example for the idea that carefully and individually looking at what each package really needs might not be such a bad idea.

Whatever "method" you prefer, that's always the case. I fail to see where using ./configure or %configure makes a difference.

And there is also the opposite, applications that live in /usr and still need --sysconfdir=/etc/opt/gnome because of gconf.

Hmm... Well.. if it uses gconf, it uses GNOME, and if it uses GNOME, it belongs into /opt/gnome in the first place. At least that's my very own interpretation.

...

%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

Duplication, either set the environment variable (only during %install, not %build) or use the configure option (but this is something else, not related to %configure).

No, because quite frequently, you have source tarballs that do *not* honor the --disable-schemas-install but check GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL instead. Usually, I only pass one of them though, after checking whether the sources properly react to --disable-schemas-install That snippet above is extracted from my template spec file for GNOME packages, where I mention both and then remove the unnecessary one (= less typing ;)).

...

I only very, very rarely encountered packages that must install into %{_prefix}/lib instead of %{_libdir} (= %{_prefix}/%{_lib}).

http://ggap.sourceforge.net/ is an example. And many, if not all Mono/C# applications, and there are more, definitely.

I rarely package Mono/C# stuff, but for the rest, http://linux01.gwdg.de/~pbleser/ as an example ;) - From the packages I do, I'd say it's 5% at most that must install into %{_prefix}/lib instead of %{_libdir} Even then, overriding %_libdir in the spec file is a more consistent approach IMO: %define _libdir %{_prefix}/lib ... %configure ... %files ... %{_libdir}/libfoo.so

...

When that happens, nothing easier than %define _prefix /usr %define _libdir %{_prefix}/lib ... %build %configure ...

Yes, but why? This is what I consider being "bloat". ./configure already does the "right thing" by default in such a case, which is wrong elsewhere, then let's make a wrapper called %configure around it that fixes other packages, but breaks this one and finally fix the fix that never fixed anything right in the spec file. It's not nice.

I just don't see that happening. %configure is not meant to fix anything. It's just commodity to pass all common configure flags. It's up to you as a packager to change the path macros where appropriate. And in my experience, with packages that have some idiosyncrasies wrt paths, ./configure almost never does the right thing without having to explicitly specify some path flags (such as --libdir).

...

What wrong ones ? I never, ever had to "fix" those options. And I currently maintain 700 packages.

The frequently wrong ones are especially: --libexecdir, --localstatedir, --sharedstatedir, but not only these. It's not that much a matter of the

- From what you wrote above, it's only these three ;) (though I don't quite agree on --localstatedir)

number of packages. Of course there are a few packages among the 700 with wrong paths in them. The point is more the "bloat" I described above, adding stuff that is never ever used in many packages, parts of which are even always wrong by design, and which makes following the difference between the package and a "normal" compilation more tricky.

You don't "add" anything, because configure sets them anyway. If you don't specify --libexecdir=..., configure will set it to whatever it thinks is the default anyway. Using %configure to set it explicitly instead of letting configure implicitly assume the value is more consistent and deterministic IMHO. Again, did you ever have sources that did *not* build correctly (or behaved correctly at runtime) because you did specify one of those flags, and that would have worked correctly if you didn't ? I never have. And when it doesn't because it requires some non-default (as of what is set as the default in rpmmacros and %_* path placeholders), you'd have to pass it to configure anyway, no matter whether you CFLAGS="%{optflags}" CXXFLAGS="%{optflags}" \ ./configure --libdir=... or %define _libdir ... %configure

Something else I dislike about %configure is that it doesn't support cases where builddir != srcdir, e.g. building object files in a subdirectory instead of the top-level directory of the source tree. OK, one might ask, why would someone want to separate builddir and srcdir while making RPMs if all the stuff is deleted afterwards anyway, but why not, and why start using a macro that is too limited to support simple out-of-source builds?

Sorry but with the exception of gcc, that's a phantom requirement. The build environment is wiped with every RPM build, so what's the point of using builddir != srcdir ?

Maybe we're lucky and the problem will vanish anyway by all packages using %__cmake, %__scons and friends next year. ;)

Heh, yeah. I really like scons, we use extensively it at work, but it doesn't make building packages a lot easier: CFLAGS="%{optflags}" \ CXXFLAGS="%{optflags}" \ ./scons \ configure \ prefix="%{_prefix}" \ %if "%{_lib}" == "lib64" libsuffix=64 %endif It is much easier to track down build problems related to the build environment though. autofools is just a big mess. But I'm afraid that's not going to be fixed any time soon ;) cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEbXpvr3NMWliFcXcRArOVAJ4vIWyAMTBRcnIkfTa3jbddqUyu5QCfZyUK vhRbiXq/wMzPdiwNF8ByBZw= =H8Kn -----END PGP SIGNATURE-----