[users] Request and a bug: gksu
jperrin at gmail.com
Mon Jun 6 21:53:47 CEST 2011
On Mon, Jun 6, 2011 at 3:06 PM, Todd And Margo Chester
<toddandmargo at gmail.com> 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
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
> 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
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 ->
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?
> 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.
More information about the users