Build requirements

Max TenEyck Woodbury mtew at cds.duke.edu
Sun Jul 21 15:01:02 GMT 2002


Richard Sharpe wrote:
> 
> On Sun, 21 Jul 2002, Max TenEyck Woodbury wrote:
> 
> Hmmm, I was responding to your complaint that BuildRequires should be
> updated and the 'implied' claim that we, the Samba team, should provide
> information about the minimum 'packages' required to build Samba.

In the .spec file I examined, there was no BuildRequires section.
The implication was that you might want to include one. You can hardly
'update' something that does not exist.

> The BuildRequires field seems to be to only be relevant to a source RPM.
> Why even bother to put it into the SPEC file for the binary RPMs we
> supply, because it represents a lot of work that must be checked each time
> we release a package for a different Linux distro. Some of those distros
> were packaging the same thing in different places and had slightly
> different names as well.

Argh. There is no 'SPEC file for the binary RPMs'. There is one SPEC file
for all the RPMs, including the source RPM. The problem is the 'Why even
bother' attitude. The answer is that including the information can prevent
problems. Once the initial part of the job is done (and I _may_ be able to
do a large part of that), maintaining it might be no worse than maintaining
the rest of the dependency information. Further, you exaggerate the work
required. It doesn't really need all that much checking. If the package
set builds, the worst that could be wrong is that the dependency information
is incomplete. If that happens, and someone has a problem, it is fairly
simple for that person to create a patch, PROVIDED the BuildRequires section
exists to be patched.

Also, you are making too much of the differences in names. You've already got
different SPEC files for the different distros, so the mechanism for handling
that part of the job is already in place.

> To provide that sort of information for all the platforms that Samba runs
> on would be a large undertaking, and to a certain extent, a waste of time
> as well, because things change.

Well thanks a LOT. I happen to be working on that problem. It is a large
problem and my progress has been slow, but being told that it's a waste of
time, is NOT helpful!

> Also, none of us have a huge amount of time on our hands, so we focus
> on the things that seem relevant.

Grrrr.

> If someone is having problems with the build environment, they are
> expected to be able to sort some of it out themselves, especially getting
> all the required tools assembled. I run into similar problems from time to
> time with Ethereal; it is an occupational hazard and I generally muddle
> through myself.

You will note that I am working the problem, and I'm trying to let you people
know about the progress I've made. If all of you don't care, then there is a
problem waiting to happen, because you are driving off people who do care.

> However, if you would like to supply some basic information based on your
> experiences, I am sure it will be accepted.

With a bunch of implicit insults in return...

OK. You've had problems with one character who made promises and didn't
deliver and screwed up others. I've tried not to make promises, but deliver 
anyway. I am deliberately trying to give you enough information about what
I'm doing so you can decide ahead of time to use it or not. Please, if you
don't understand the problem, do NOT simply insult the person who is 
describing the problem to you. That may make the person go away, but it
will NOT make the problem go away.

> Finally, while you might already know this, a script that can find which
> 'uninstalled' package a particular file comes from is:
> 
> mount /mnt/cdrom
> cd /mnt/cdrom/RedHat/RPMS
> for f in *.rpm
> do
>   if [ "`rpm -qlp $f | grep <some string>" ]; then echo $f; fi
> done
> 
> You will, of course, have to run this for all of the CDs :-( and there
> might be subtle errors in the above. I typed it in from memory.

You could use 'find' instead of the for loop, you've ignored the problem
of secondary and deeper dependencies, and ignored the fact that builds
require variant forms of the required library packages rather than the library
packages themselves. For example, I didn't need ssl which contains 
libcrypto.so.2 and was already installed, I needed ssl-devel. It's not an easy 
problem. That's why my progress has been a bit slow on the bigger project. And 
when I'm done, you might just be able to use what I've done to help with your 
Ethereal problem.

Note to self: While a 'grep "\#include" ...' might miss stuff, automake 
probably has a piece that can be borrowed to identify all the includes. Feed 
that to the file/package locator and add the result to the dependency list 
with a tag that it is needed for the build only. Use the grep hack until I've
got 
time to read the automake docs and/or dissect the automake code. Also, set
up a place to put this kind of notes on pieces that haven't reached the
detailed specification stage rather than posting it!

mtew




More information about the samba-technical mailing list