Bug 194185

Created attachment 130583 [details]
Matt Domsch's build log

pkgconfig: command not found !
Why ? I would assume that tools required to build the package ought to be
present on a build root !

Daniel

pkgconfig is not in the base config for mock. If it fails to be installed, its
usually because a *-devel package does not have a "Requires" on it. 

Okay, so give me the liste of BuildRequires needed to compile C program
in your shiny new environment ! No way I'm gonna track down all dependancies

 Do I need

BuildRequire: ld
BuildRequire: cpp 
BuildRequire: gcc
BuildRequire: automake
BuildRequire: autoconf
BuildRequire: /bin/sh

 where do you draw the line ? I though the line was building tools should
not be required and pkgconfig is a build tool, it has strictly no other use

Let's say that having to go though all my spec file to add those completely
redundant lines is a complete waste of time. Apparently developpers time
is cheap, computer time are scarce, interesting ...

One of the key finding of programing analysis is that it doesn't matter
how hard or simple the code is, you will get a bottom minimal percentage 
of bugs in code strictly correlated with the number of line. Forcing to 
add more line, means adding more bugs, if those lines can be made superfluous
based on infrastructure by all means get rid of them, that's one of the few
things 30 years of research in grogramming techniques have taught us. 

Daniel

Initial Core clean up announcement to fedora-maintainers:
https://www.redhat.com/archives/fedora-maintainers/2006-May/msg00036.html

The email to fedora-devel announcing the rebuild with the reduced buildgroup list:
https://www.redhat.com/archives/fedora-devel-list/2006-May/msg00802.html

Jesse's email to fedora-maintainers asking reminding everyone that the core
clean up is needed for FC6test1:
https://www.redhat.com/archives/fedora-maintainers/2006-June/msg00005.html

As for the missing buildrequires, it looks like you need libxml2-devel, which
should have a Requires: pkgconfig, if it doesn't, then that is where the fix
should be. 

Of course xmlsec1.spec does have BuildRequires: libxml2-devel >= 2.6.0

W.r.t. embedding the Requires: pkgconfig for each and every devel section of
spec files, that ought to be computed automatically, if we can compute
.so dependancies, damn finding there is a %{prefix}/lib*/pkgconfig/*.pc file
should really be automatic and not require more verbiage in the spec !

  I still maintain most of this is putting the work and maintainance pressure
on the most scarce resource: the maintainers !

Daniel

Daniel, pkgconfig is not used for many many packages.  The new build system
starts with minimal assumptions about what should be in the build root.  Adding
things beyond the most basic of assumptions leads to major problems when trying
to build packages outside that build environment.  We care about our users and
their ability to use our packages.  We care about having carefully managed build
environments so that a package is built in the env that the PACKAGE wants, not
just a full install of the distro.

I'm sorry this is extra work.  If the package was clean to begin with, you
wouldn't have noticed anything.  The community at large is giving us a great
helping hand to clean up our packages and work toward the spec quality that has
been set forth by the Extras packaging community.  Please do take a moment to
ensure your package builds correctly.

"If the package was clean to begin with"

  I still have to understand what is 'unclean' in xmlsec1, nothing I guess.
The "moment" is currently more than one hour. It included changing the spec file
from libxml2 upstream (yes the spec come from upstream, and any new silly rule
makes me change things there too).

  I am not even sure it's proper, as the configure.in uses pkgconfig, so 
logically it's a BuildRequire from xmlsec1, not a requirement to use libxml2
developpment.

If one use pkgconfig, one pays for this extra maintainance step, if one doesn't
use it then the scripts replacing it (like xml2-config) conflicts with the
multi-lib new requirements. Being a maintainer for packages in Fedora Core
is really getting a bad place to be, honnestly it's not fun.

Daniel

Making assumptions about what will be in your buildroot isn't fun either.  So
perhaps you do need to make it a BR of xmlsec1.  This is one of those somewhat
grey areas.  libxml2-devel has .pyc files, but could be used w/out pkgconfig, so
it is not a real hard requirement.  However since xmlsec1 makes use of
pkgconfig, it really should BR pkgconfig.

By "clean" I meant not making assumptions about what will be in the buildroot. 
There are actual packaging standards now, all new Fedora packages must adhere to
them.  This is for both new Extras packages and new Core packages.

http://fedoraproject.org/wiki/Packaging/Guidelines

Daniel, have these packages been built into rawhide yet?

I am trying to rebuild the newly release libxml2-2.6.25 in rawhide with that
change and also the Red Hat specific patch for xml2-config induced by the 
multilib madness. 
No garantee it will work out as expected, and I'm about to release libxslt,
I will have to look at the same multilib crazyness for it and xmlsec1.

Daniel

Okay libxml2-2.6.26 is built in rawhide, I hope it fixes the problem.

Daniel