Menu
▾
▴
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
|
From: Doug N. <sci...@ou...> - 2014-09-30 05:42:07
|
---------------------------------------- > Date: Tue, 30 Sep 2014 15:08:04 +1000 > From: on...@gm... > To: enl...@li... > Subject: Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value' > > > On Mon, 29 Sep 2014 23:28:53 -0500 Doug Newgard <sci...@ou...> > wrote: > > > > Date: Tue, 30 Sep 2014 14:07:52 +1000 > > > From: on...@gm... > > > To: enl...@li... > > > Subject: Re: [E-devel] libeeze.so: undefined reference to > > >`udev_device_set_sysattr_value' > > > > > > On Tue, 30 Sep 2014 13:19:20 +0930 Graham Gower > > > <gra...@gm...> wrote: > > > > > >> On 30 September 2014 11:37, Doug Newgard <sci...@ou...> > > >> wrote: > > >>> If you're entire system is that old, I'm sure EFL from 2.5 years > > >>> ago will run just fine as well. > > > > > > Actually, EFL from 2.5 years ago was just as bleeding edge at the > > >time as it is now, and still unlikely to run on stable systems from > > >2.5 years ago, which did not use bleeding edge stuff from 2.5 years > > > ago. :-P > > > > I don't know if you didn't understand my point or if you're just > > ignoring it. If it takes 2.5 years for software to be considered > > "stable", go back and install the various libs from 1.4 and you > > should be great! Match the version of EFL to the rest of your system. > > You missed my point, the 2.5 year old EFL was bleeding edge 2.5 years > ago, and still not good for a 2.5 year old stable system. Oh I understood your point perfectly, but it's totally irrelevant. I'm not telling you to install 2.5 year old libs on a 5 year old system, but 2.5 year old libs on a 2.5 year old system. Makes a twisted kind of sense, doesn't it? Your own reasoning says that the pre-1.7 libs are just now becoming "stable", so why not use them? > >>> Slackware 14.1, released Nov 2013. This is not old unless you're > >>> accustomed to releasing a new version of your software every 2-3 > >>> weeks. > >> > >> There's no arguing with those that insist every one use the most > >> bleeding edge systems. You can't change their minds. It also seems > >> useless trying to keep the large and every growing list of > >>dependencies down to a manageable roar. > > > > It is indeed hard to argue with someone who insists on installing > > bleeding edge software when everything else on their system is > > ancient. Can you really not see that that's a recipe for disaster? > > "Stable", not "ancient". Get that through your head please. There are > many many people that use stable systems, this is why such systems are > provided by popular Linux distros. This is the point of the "long > term" part of "long term stable", you can rely on them being stable > over a long term of many years. I'll stick with "ancient", since it really describes the situation better. "Stable" is not determined by time, "ancient" is and that seems to be what's important in these distros that use ancient software. > > It's not a recipe for disaster, it's done all the time. Install a > bleeding edge window manager, fine it shouldn't impact the rest of the > system. The stable window manager the OS defaults to can be left alone > and used as a backup for when the bleeding edge one falls over. Install > a bleeding edge window manager that gratuitously depends on a bleeding > edge version of an important sub system, yep THAT's a recipe for > disaster, and exactly why it's not such a good idea for said window > manager to depend on bleeding edge stuff. Installing a window manager > that gratuitously depends on an important sub system that is itself > graciously different from what some others do is even worse. > > The base OS is stable, but you can use a stable OS for development of > bleeding edge software, or install bleeding edge bits. Lots of > development companies do that. So long as you don't replace stable > bits that are crucial to the OS in general with bleeding edge bits, > it's all good. Things like udev and systemd are kinda crucial bits, or > replace crucial bits in stable systems that didn't use systemd or udev > in the first place. And this is the crux of the issue. You believe that all software must be backwards compatible to the beginning of time, I do not. By the time your current software gets into distros, the current version of libs will as well. Having to add a bunch of logic for APIs that have been obsolete for 5+ years does nothing except dirty up the code. Note that the lib in question here is already a year and a half old. By the time EFL is shipped in a distro, it *should* already have the necessary version. Calling this bleeding edge is really stretching things beyond belief. > > There was mention in this thread that eeze being just a thin layer was > a bad idea, and it should have been a higher abstraction API. Then you > wouldn't be depending on ONE bleeding edge important sub system that > some people don't use for various reasons. Flexibility in this area is > important. A bit less important for stuff that's not so crucial. > -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enl...@li... https://lists.sourceforge.net/lists/listinfo/enlightenment-devel |