Hi,
> 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.
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.
> 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:
./configure \
--prefix=%{_prefix} \
--exec-prefix=%{_exec_prefix} \
--bindir=%{_bindir} \
--sbindir=%{_sbindir} \
--sysconfdir=%{_sysconfdir} \
--datadir=%{_datadir} \
--includedir=%{_includedir} \
--libdir=%{_libdir} \
--libexecdir=%{_libexecdir} \
--localstatedir=%{_localstatedir} \
--sharedstatedir=%{_sharedstatedir} \
--mandir=%{_mandir} \
--infodir=%{_infodir}
--prefix=%{_prefix}: OK, nothing to worry about. Will be redefined if
necessary.
--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.
--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.
--datadir=%{_datadir}: OK, nothing to worry about, but completely unnessary
to specify.
--includedir=%{_includedir}: A reasonable default, no need to specify
explicitly.
--libdir=%{_libdir}: OK for the majority of packages, but wrong for some
exceptions.
--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)
--localstatedir=%{_localstatedir}: Defaults to /var. Always wrong!
Candidates are:
/var/lib/%{name}
/var/lib
/var%{_prefix}/%{name}
/var%{_prefix}
/var/cache/%{name}
/var/cache
--sharedstatedir=%{_sharedstatedir}: Defaults to /var/com. Always wrong!
Candidates are the same as for --localstatedir.
--mandir=%{_mandir}: Correct for packages whose %{_prefix} is either /usr
or /opt/gnome, but wrong for all others, especially / and /usr/X11R6.
--infodir=%{_infodir}: Same as --mandir.
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.
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.
Sometimes it can be dangerous because packagers might think that
%configure automagically does the "right thing" for them even if it
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.
> 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.
> # 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?
> 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.
And there is also the opposite, applications that live in /usr and still
need --sysconfdir=/etc/opt/gnome because of gconf.
> %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).
> 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.
> 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.
> 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
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.
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?
Maybe we're lucky and the problem will vanish anyway by all packages using
%__cmake, %__scons and friends next year. ;)
Andreas Hanke
--
Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer!
Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
