On Fri, Feb 24, 2012 at 06:27:24PM -0600, al...@verizon.net wrote: > > At the very least, your answers have helped me sharpen > my big question which, after all, is based on this actual, > immovable fact: > > 'udev-181' expects to find in '/usr/include/linux' a file, > 'input.h', which contains the definition of a so called > BTN_TRIGGER_HAPPY. Good, OK. I understand. > > Another secondary fact (which is most likely on me), > my current '/usr/include/linux/input.h' does NOT contain it. > Maybe because file too old, a mistake/omission in 6.7, etc., etc. > Bad, Not-OK. > Udev has a reputation for being unpleasant and not backward-compatible. In the (distant) past I upgraded some old systems because of a udev vulnerability, but it's not something I would expect to work as a matter of course for any random version of udev. In fact, for some I had to stick with an old verison and use patches from debian.
The LFS book is concerned with building a new system. Compare udev in BLFS where we say: Unlike any other package in the BLFS book, there is no set version of Udev specified to download. Several version updates to LFS and none to BLFS means there are probably many different versions of Udev on the platforms that BLFS is being built upon. Therefore, you should download and use the version of Udev your computer currently uses. What we don't add is that the build instructions for each version of udev change, so you *really* need to keep the version of the LFS book which you used (or your LFS udev script, if you have one) around to be able to rebuild udev if you need to - I had that recently when testing gnome-3, several packages need a fuller udev and I had to go back to my original LFS script to sort it out - that was one place where running the testsuite stopped me installing a b0rken version (said the man who normally trusts testsuites only as far as he can throw them). > ------ > > Now I can crystallize my "header" question a lot more. > > We know an 'udev-xxx' (say, 'udev-173') did not need > BTN_TRIGGER_HAPPY, while a later udev (say, 'udev-181') > aware of a _newer_ 'input.h' file floating around, > which does contain BTN_TRIGGER_HAPPY, expected the user > (i.e., me) to have this file in '/usr/include/...'. > > Based on that, here's (finally) the finalized question: > > IF I'm up to date with the LFS book, and am at > the latest Glibc, v2.14.1 (issued 07-Oct-2011, FWIW) > no matter what kernel version was at the time (say, 3.0.9) > - assuming I compiled Glibc-2.14.1 in Nov. 2011 - > the "sanitized" headers installed as per Book 6.7 > provide a guaranty for me that they contain the "correct" 'input.h' > for as long as I stay with Glibc-2.14.1, no matter what > the udev version du jour (181++) might be. > > Or put another way around, udev-173++ developers rely on > and expect me to have the Nov. 2011 headers (sanitised:) > and as for me, I'll be fine for any future udev release, > as long as the Glibc stays at 2.14.1. > > Is that so? You seem to think that we support upgrading an existing system in-place. For trivial packages in BLFS, and indeed for many packages in LFS, that usually works. For others, such as glibc, we do not advise it - sometimes works, other times trashes the system. > > BTW, I didn't know that developers (udev and otherwise) are > continuously careful to stay within the latest Glibc-thenKernel confines. > > -- Alex > > PS - I don't have any idea when BTN_TRIGGER_HAPPY made its > way into 'input.h'. Too bad. It'd've been interesting. Google suggests 2.6.34-rc1, and found a report that udev-172 did not compile because it needed BTN_TRIGGER_HAPPY. Curiouser and curiouser. Sorry this wasn't the reply you wanted. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
