Bug 194185 - xmlsec1 fails to build in mock
Summary: xmlsec1 fails to build in mock
Alias: None
Product: Fedora
Classification: Fedora
Component: xmlsec1   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Daniel Veillard
QA Contact:
Depends On:
Blocks: BuildReqBlocker
TreeView+ depends on / blocked
Reported: 2006-06-06 00:05 UTC by Michael J Knox
Modified: 2013-01-10 03:55 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-06-06 16:56:14 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Matt Domsch's build log (12.06 KB, text/plain)
2006-06-06 00:05 UTC, Michael J Knox
no flags Details

Description Michael J Knox 2006-06-06 00:05:37 UTC
This package fails to build in mock.  build.log is attached.

Comment 1 Michael J Knox 2006-06-06 00:05:37 UTC
Created attachment 130583 [details]
Matt Domsch's build log

Comment 2 Daniel Veillard 2006-06-06 07:54:55 UTC
pkgconfig: command not found !
Why ? I would assume that tools required to build the package ought to be
present on a build root !


Comment 3 Michael J Knox 2006-06-06 08:07:47 UTC
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. 

Comment 4 Daniel Veillard 2006-06-06 08:26:34 UTC
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. 


Comment 5 Michael J Knox 2006-06-06 08:42:26 UTC
Initial Core clean up announcement to fedora-maintainers:

The email to fedora-devel announcing the rebuild with the reduced buildgroup list:

Jesse's email to fedora-maintainers asking reminding everyone that the core
clean up is needed for FC6test1:

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. 

Comment 6 Daniel Veillard 2006-06-06 09:35:15 UTC
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 !


Comment 7 Jesse Keating 2006-06-06 12:40:21 UTC
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.

Comment 8 Daniel Veillard 2006-06-06 13:37:56 UTC
"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

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.


Comment 9 Jesse Keating 2006-06-06 14:28:52 UTC
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.


Daniel, have these packages been built into rawhide yet?

Comment 10 Daniel Veillard 2006-06-06 14:38:50 UTC
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.


Comment 11 Daniel Veillard 2006-06-06 16:56:14 UTC
Okay libxml2-2.6.26 is built in rawhide, I hope it fixes the problem.


Note You need to log in before you can comment on or make changes to this bug.