On Tue, Sep 22, 2015 at 03:43:43PM -0400, alex lupu wrote: > The subject of "dependencies" has come up in our posts quite frequently > so I'd like to respectfully add my recent experience to the accumulated > lore. > That all sounds fine, so I'll just add a little information about gudev.
> I didn't have any JS but I installed it anyway :-) It went smoothly. > (it required libffi-3.2.1, NSPR-4.10.9, Python-2.7.10 and Zip-3.0; > I had the right libffi, a NSPR-4.10.8, a Python-2.7.9 and the right Zip) > Yeah, one of the -Kit packages got reworked to use JS. > Finally, I'm getting to the clincher, the "vanishing" libGudev. > On my system, all I have is a 'libgudev-1.0.so.0.1.0', cca., 2011. Hmm, 2011 is getting a bit old - so many vulnerabilities have become known since then. > May or may not be related to UDEV. I had stopped updating udev a while > ago (life is too short and my hardware is not too fancy, anyway. > FWIW, my library is at 'libudev.so.0.13.1', cca., 2012). > > I have no idea what the relationship between libGudev-230 and my version > of it(?), libGudev-1.0. I have to assume they are pretty different > (I do gnot have any Gnome environment - as opposed to KDE, for example > so I don't gnow much, if at all, about what they are). > I did try to install libgudev-230 brute force (requires GLib-2.44.1 - fine) > but, as more or less expected, it failed hard immediately: > > Package requirements (libudev >= 199) were not met: > Requested 'libudev >= 199' but version of libudev is 182 > > BTW, this has led me to conclude I have unfortunately reached the end of > the line with udev + gudev combination. > Libgudev used to be part of udev, so when systemd ate that it got pulled in by systemd / udev-from-systemd / eudev. In the past few months, it got spat out again, to become a separate project. > To my surprise (and actually the point of this post), UPoweer-0.9.23 > compiled > and installed perfectly, and it has even been doing the job I needed it to. Good. With a working udev or its derivatives/extras I try not to upgrade unless there is a known vulnerability (the last one was several years ago). > (to be fair, the 'make check' didn't like something, > > ERROR: up-self-test.c: 225: up_test_history_func: > assertion failed (array->len == 2): (3 == 2) > No idea - for most packages in BLFS I do not run the tests :) > but it didn't seem to me as a show stopper and/or related to the missing > libgudev). > > ------ > Please note the above description of a successful package build despite > missing a major(?) dependency was not intended as a statement, just a humble > sharing of a recent personal experience (as opposed to discussing graphs of > dependencies and such. I've never been too crazy about graphs especially > acyclic - however, circular graphs I'm all for. I like to know that I can > always come back to where I started). > > Nor as a "technical" analysis. My simple-minded explanation is that > somewhere, somehow on my system there must be something that compensates > for the missing libgudev dependency !? > I think your existing gudev turned out to be perfectly adequate for this version of upower. NB this is now an *old* upower, the newer version is much more relevant to systemd (see e.g. gentoo ebuild scripts and forum posts for things which they had to change but we don't). > So, in summary, to paraphrase (if I may) Ken's wise dictum, > "Your system(s), your choices", my experience would say, > "Your system(s), your dependencies". > LOL. Glad it's working for you. > Cheers, > -- Alex ĸen -- Il Porcupino Nil Sodomy Est! (if you will excuse my latatian) aka "The hedgehog song" -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
