pam src rpm replaced?
Mike A. Harris
mharris at redhat.com
Sun Aug 24 06:54:29 UTC 2003
On Sat, 23 Aug 2003, Michael Schwendt wrote:
>> While I am at it, I reported a simple missing BuildRequires for pam three
>> weeks ago, but I haven't seen any reaction on bugzilla yet
>> (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=101563).
>
>Well, activity log disagrees:
>https://bugzilla.redhat.com/bugzilla/show_activity.cgi?id=101563
>
>> Why does it
>> have to take so long just to fix such a simple bug for which a fix is
>> provided? Not that I expect new pam rpms to be released for a single
>> BuildRequires, but a simple "this will be fixed in the next release" would
>> be nice.
>
>Concerning missing buildrequires, it would be nice if someone from Red
>Hat could post a short comment on how clean their build environment is
It depends on what exactly you mean by "how clean is the build
environment". That question could be interpreted in 10 different
ways by 10 different people. Can you be more specific?
The Red Hat build machines contain an installation of some
version of Red Hat Linux or Red Hat Enterprise Linux (depending
on the particular machine and various other factors). That OS is
what "hosts" the machine and the version doesn't matter very
much. Every build machine has a number of "buildroots" installed
on it, which are essentially a complete installation of a
particular version of Red Hat Linux or Red Hat Enterprise Linux
installed into a subdirectory which builds for that particular
operating system version can be done, by chroot'ing into the
particular buildroot directory and an rpm build being performed.
The creation of these clean buildroot "chroot jails" is automated
by the buildsystem, and populated with a complete set of RPM
packages that make up the given OS release the buildroot is for.
Any erratum updates released by us are also applied to the
buildroot so that all of our software builds are built with the
latest updates to the OS.
When developing a new OS release, such as the currently codenamed
"Cambridge", a buildroot is instantiated based on the last OS
release (in this case Red Hat Linux 9), and all packages built
for the developmental release get built in this new developmental
buildroot. The buildsystem automatically installs BuildRequires
dependancies named in the RPM specfile to ensure that all
packages being built have their build time dependancies met.
Since the whole process of creating the buildroots, upgrading
packages in the buildroots, and building RPM packages is
completely automated, the buildroots and thus the buildsystem is
fairly "clean" WRT what versions of what software are installed
on a given buildsystem and buildroot at a particular time.
Does this answer your question about how clean our build
environment is?
>and whether they are interested in learning about src.rpm build
>problems.
Absolutely.
If there are build problems rebuilding a particular src.rpm, we
definitely want to know about them. A lot of problems like this
that get reported, get fixed rather quickly.
Some problems that get reported, such as build problems
experienced when people use a proprietary C compiler or other
tools not provided or supported by Red Hat, we will close as
WONTFIX. There are other cases where a reported build time bug
might be considered unsupported by us, but the majority of
reported bugs of this nature are usually something that we want
to know about. If in doubt, report it, and if we disagree, we'll
let you know. ;o)
>Maybe flex is an essential component in Red Hat's build
>environment? Similar to gcc/g++/make and a few other tools.
>There are other packages with incomplete build requirements
>which fail to build in a clean environment.
flex is definitely something required by the buildsystem at all
times. If you discover any RPM packages missing BuildRequires,
or missing Requires or other dependancies or conflicts, please
report them.
Also note that some dependancies aren't always as they appear at
all times. I recently had a bug report that XFree86-xfs required
gzip in order to work properly, and that Requires: gzip was
missing from the package. After close examination of the
XFree86-xfs binaries, shell scripts, etc. I couldn't find
anything that used gzip. I assumed that something else used by
the XFree86-xfs package was missing a gzip dependancy. After a
small amount of troubleshooting, I found the culprit to be
ttmkfdir internally calling gzip. The proper dependancy in this
case was ttmkfdir needing a "Requires: gzip" and not the
XFree86-xfs package.
If possible, when you determine a missing dependancy on a
package, be it a compile time, install time, or run time
dependancy, please try to pinpoint the exact reason for the
dependancy to ensure that the proper package gets fixed. This
helps to lower the minimum install requirements, and makes things
much more snazzalicious.
;o)
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
More information about the fedora-test-list
mailing list