pam src rpm replaced?
Mike A. Harris
mharris at redhat.com
Sun Aug 24 07:07:39 UTC 2003
On Sun, 24 Aug 2003, Michael Schwendt wrote:
>> I noticed the adding of this bug to 100644, but it's just the actual
>> maintainer hasn't reacted to it.
>
>Would that change a thing? No. Just imagine the maintainer wastes a
>few seconds on a "will be fixed in next release" comment, but then
>forgets to fix it actually. ;) Missing buildreqs run at very low
>priority unless a src.rpm breaks in Red Hat's own build environment.
>The maintainer will [hopefully] add a comment or close the report when
>the bug is fixed in the spec file actually.
It's also possible that a given maintainer might be on vacation.
Also, adding new dependancies often takes more time than just
adding a line to a spec file. Personally, any time someone
requests a new BuildRequires, Requires, or somesuch dependancy on
one of my packages, unless the dependancy is extremely obvious
that it is needed and is missing, I investigate what specifically
in the package does really require that, as I hate to add
unneeded dependancies to a package. Occasionally, the real
dependancy isn't the one the package the bug is reported against,
but rather the bug is a missing dependancy in one of the other
packages which the package requires that the bug is reported
against.
It might seem a bit tedious to investigate these things to that
level, but unneeded dependancies only complicate packaging and
make the minimal distro install size increase. Also, in the case
of package1 requires package2 which is missing dependancy A, if
you add the dependancy to package1 without investigation, any
other package in the distribution that requires package2 will end
up missing that dependancy as well. It's always best to search
for the proper dependancy unless it is drop dead obvious. ;o)
>> > Maybe flex is an essential component in Red Hat's build
>> > environment?
>>
>> If that were so some package my current setup should require it.
>
>Wrong assumption. gcc-c++/make/gettext, for instance, are no package
>build requirements either. So, basically every C++ application would
>not build with your setup. But of course, you have installed those
>packages deliberately. Or because they belong to the development
>group.
Yes, some packages like gcc, etc. are obvious to not require
BuildRequires. There are others too, however it never hurts to
report one of these in case it is considered a legitimate bug.
Perhaps we should have a "development-base" package, that
Requires all of these things, just to ensure all truly required
packages are installed in development installs? That might be a
good suggestion.
>> > There are
>> > other packages with incomplete build requirements which fail to build in a
>> > clean environment.
>>
>> Can you name a few?
>
>Sorry, no space left in my brain for such a list. Occasionally you
>stumble upon such packages, provided that your build environment is
>really pretty close to "clean" (with regard to -devel packages and
>lots of tools). And Red Hat seem to have had no problems building
>those packages, because their build environment is different from
>"just rpm-build and dependencies".
Correct. If I understand correctly, our buildsystem installs a
certain number of hard coded applications considered minimum
requirements for doing development. The C compiler, C++
compiler, and whatnot are all included. A lot of -devel packages
I believe are also included. The rest of the -devel packages get
included by a particular src.rpm listing it as a BuildRequires.
So for example, if I try to compile XFree86, and Glide3-devel
isn't installed on a buildmachine in a buildroot, the buildsystem
parses that XFree86 needs Glide3 and Glide3-devel to compile
automatically, and it installs those packages first, prior to
initiating the build. If that package (Glide3, and Glide3-devel)
have dependancies that are also not installed, the buildsystem
will continue to install all of the required dependancies until
the build can proceed.
So, generally our build systems always have all software
installed to compile anything in the OS, and if not, they will
automatically install a given component when it is needed by a
given build (assuming the package exists). If a package doesn't
exist and is a buildrequire, then the build will fail, and we go
running to find the problem and fix it. ;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