Forum Home
Press F1
 
Thread ID: 60855 2005-08-15 10:46:00 Broke my Mandrake dolby digital (5073) Press F1
Post ID Timestamp Content User
381459 2005-08-15 10:46:00 Well I was having problems with the Mandrake Perl install; so I installed the Perl source and compiled it. Fixed the other problem I was having but now the Mandrake GUI tools are busted. They must use Perl when building these tools. Linux still runs, and I can run non Mandrake GUI programs ok. Tempted to install Vector Linux 5.0.1 SOHO :waughh: dolby digital (5073)
381460 2005-08-16 00:50:00 Yeah, most build scripts I have come across are written in Perl. But an app that has already been built should be no problem.

Try uninstalling and reinstalling the GUI using the new Perl.
vinref (6194)
381461 2005-08-16 02:06:00 Perl is an interpreter, so "reinstalling the GUI" will make no difference. The version that's there when the application is run is the one which matters.

Did you compile and install an older version of Perl? That's the only thing which should stop applications from working. Newer versions go through a intensive testing to make sure they don't break code which worked on older versions. However, old versions haven't been tested to ensure they don't break applications which are still in the future.
Graham L (2)
381462 2005-08-16 05:55:00 Perl is an interpreter, so "reinstalling the GUI" will make no difference. The version that's there when the application is run is the one which matters.

Whatever Perl's function in the GUI apps is, this sounds like a classic dependency problem - change a component and something no longer works. Re-installing the broken app usually resolves the dependency as the build script picks up the new version.

Doesn't the Mandrake packaging system pick up newly installed versions and update the dependencies?
vinref (6194)
381463 2005-08-17 02:28:00 One thing it's not is a "classic dependency problem" . It's more likely to be just a user problem .

Perl, or any other language processor, is not "dependent" on its user applications . It can't be . It's a language processor . As I said, a new, improved, language processor, like the system libraries ("DLL"s) should have been tested so applications which work with previous versions don't break . If a user installs an older version, (e . g . , version 3) of a language processor (or system library) that an application (or its scripts) has been written to use, things dependent on having (say, version 5 or later )of a processor) might break .

A GUI is likely to use any new features in the verison of languiage processors current at the time it are being writtten . It will rely on them . If they aren't in the older processor, it will fall over .

I suppose, reinstalling the GUI might cause the appropriate version of Perl to be installed . (because the GUI is dependent on the Perl version) . It seems a bit of an overkill . That't the sort of thing that Windows people do, like reformatting the disk to change the baud rate of a modem .
Graham L (2)
381464 2005-08-17 03:41:00 One thing it's not is a "classic dependency problem" . It's more likely to be just a user problem .

You are being pedantic . Something worked before, change something else, and now it doesn't work . It is a dependency problem . It happens in Windows, it happens in Linux, it happens in Unix, it happens in *BSD .


Perl, or any other language processor, is not "dependent" on its user applications . It can't be . It's a language processor . As I said, a new, improved, language processor, like the system libraries ("DLL"s) should have been tested so applications which work with previous versions don't break . If a user installs an older version, (e . g . , version 3) of a language processor (or system library) that an application (or its scripts) has been written to use, things dependent on having (say, version 5 or later )of a processor) might break .

You're confused . Perl is a dependency in dd's case, not the dependant . The GUI tools (or whatever it is), depends on Perl, not the other way around . As far as I have experienced in application building and installation in Linux and *BSD systems, Perl is used in the build scripts - interpreted languages are most suitable for this task . It is not a run-time dependency .

From what I can assume about dd's problem, he re-installed Perl manually for whatever reason - very bad idea unless you know where the various files and objects go . In a large complex system like Mandrake, it is best to let the packaging system handle that . He then tried to re-build(?) the GUI apps, but found that they would not - it's build process cannot find Perl and/or its various files and objects .


I suppose, reinstalling the GUI might cause the appropriate version of Perl to be installed . (because the GUI is dependent on the Perl version) . It seems a bit of an overkill . That't the sort of thing that Windows people do, like reformatting the disk to change the baud rate of a modem .

Overkill? Re-installing (if the Mandrake packaging system is smart enough) will restore Perl and all its files and objects in the right places for all existing and new applications to see . Under no circumstances should you to try to manually resolve the dependencies unless you know the filesystem and the package database very well, and have read the README and the Makefile twenty times over .
vinref (6194)
381465 2005-08-17 04:07:00 Yes, I am pedantic . Computers are nasty beasts which do exactly what they are told . 40 years after I wrote my first computer programme, I still try to use language accurately . Even when I'm not writing code .

Something worked, the user changes something; it no longer works . It's a user problem .

"You're confused . Perl is a dependency in dd's case, not the dependant . The GUI tools (or whatever it is), depends on Perl, not the other way around . "

[I'm not confused . That's what I wrote .
Graham L (2)
1