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