-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[EMAIL PROTECTED] 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/
/\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
_\_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-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
