On Mon, Jun 6, 2011 at 3:06 PM, Todd And Margo Chester <[email protected]> wrote:
> No one actually stated the reasons. Nor did I say they did. I said it was already stated to be bad, and it's bad for several reasons. > Using older piece of code is a problem, why? Everything in Enterprise > Linux is old. That is the idea. Why would this particular piece of > older code > be an issue and the thousands of other pieces of older code in EL > not be a problem? I do not understand. (Out-of-date Firefox drives me > nuts.) Not all enterprise linux is equal. Just because el5 and el6 are both 'enterprise' doesn't mean that you can go mixing packages interchangeably. While you may think el6 is already out of date, it's 3-4 years newer than el5 software. The kernel (and kernel ABI) have changed, as have python versions, glibc (the core library which is depended on by nearly everything), the compression used for rpm, yum, and on and on and on. It's all newer, it's not all 100% backwards compatible. Installing el5 packages on el6 installs and expecting it to 'just work' shows a fundamental failure of understanding for how linux in general operates. > I would think that the paths are hard coded in the package. So, I would > also think they would behave exactly the same in el5 as el6. Not "shocking" > at all. Do the paths somehow float around depending on the revision of > the kernel? Am I mistaken? Is there some dependancy statement: How you think it should operate and how it may actually operate aren't always the same thing. This is why I asked the question. Testing is important. Yes, paths may change based on what version of something is in use. There are a number of applications like this as well as many spec files within the rpmforge arsenal that have conditional builds and path modifiers based on the el version they're targeting. > > if el5 > then helper=/usr/lib64/libgksu/gksu-run-helper > elif el6 > then helper=/usr/lib/libgksu/gksu-run-helper > endif > While not true for this particular package, this is indeed the case for many packages. Hell, even the rpmforge-release package has this exact sort of logic built into the spec file for compile-time operations, and there's essentially no source code to build. To see an example of this have a look at -> http://dries.ulyssis.org/rpm/packages/rpmforge-release/rpmforge-release-spec.html What you're describing is far from an unusual case. > I would presume the path to gksu-run-helper was simply > hard coded. What am I missing? Experience. > So, yes, it reproduces on el5. So file the bug against el5. Don't bitch that something doesn't work on a system it wasn't built for. Bitch that it doesn't work on the system it WAS built for. > Now that is "shocking". Not really. :-) Your snark would have more weight if you made the effort to learn a bit more about the software you use and the path it takes from source to packaged install. -- During times of universal deceit, telling the truth becomes a revolutionary act. George Orwell _______________________________________________ users mailing list [email protected] http://lists.repoforge.org/mailman/listinfo/users
