This isn't specific to some particular package, I've seen it in several
packages already.......
Usually when we test packages, we simply build it, then install it. No
problem afterwards. However there can be some bugs or packaging problem
that we can't notice if we test it this way.
Take kernel as example. When compiling split-include, it includes some
other headers which includes yet others. "linux/errno.h" was one of
them. However, since include path is not properly defined, kernel is using
/usr/include/linux/errno.h, not the one included in new to-be-compiled
kernel package. That means kernel needs kernel header already installed in
order to compile. I've asked this once in cooker list and nobody
noticed...... probably because it is too minor and very few ppl are
trapped this way.
Not only kernel, but db1 and db3 behaves the same way ---- they need
themselves already installed in order to compile. Doesn't that sound too
interesting?
If that's not enough, I can tell one more. Sometimes I really can't figure
out why some source RPM can generate their corresponding binary RPM. When
trying to compile db3, it complains "db.h" not found in the nss_db stage
-- it's running configure in nss_db, to be exact. I *REALLY* don't know
which package contains "/usr/include/db.h" !!! Can anybody tell me if I'm
wrong, and some package really contain /usr/include/db.h?
Btw, I believe what I saw is just a very small portion of all. I
understand developers hardly have time for anything else except refining
software/packages, so don't mean to complain here ---- just want to tell
others such problem exists (guess very few people observed it).
Abel Cheung
