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
