I have a working SuSE 9.0 system which I use. All of the packages are off the 9.0 CD's and I 'prefer' to only use SuSE compiled RPM's as then I know files are going to be installed in the correct place, wherever that may be. From time to time I see software package updates, either on CD or the web but they are for another distro ie Mandrake and perhaps others. Is it possible to use those RPM's via YaST and still have them install in the correct SuSE locations or as it might be a Mandrake RPM it will install in locations Mandrake would have. Basically the question revolves around location, location, location. Being in the right place at the right time, is crucial to property and most other things and I wonder if the installed location is as important or different between distros using the same package format? As both Mandravia and SuSE subscribe to the FHStandard can the above assumption be made? Regards -- ======================================================================== Hylton Conacher - Linux user # 229959 at http://counter.li.org Currently using SuSE 9.0 Professional with KDE 3.1 ========================================================================
On 5/9/05, Hylton Conacher (ZR1HPC) <hylton@global.co.za> wrote:
I have a working SuSE 9.0 system which I use. All of the packages are off the 9.0 CD's and I 'prefer' to only use SuSE compiled RPM's as then I know files are going to be installed in the correct place, wherever that may be. From time to time I see software package updates, either on CD or the web but they are for another distro ie Mandrake and perhaps others.
Is it possible to use those RPM's via YaST and still have them install in the correct SuSE locations or as it might be a Mandrake RPM it will install in locations Mandrake would have.
Basically the question revolves around location, location, location. Being in the right place at the right time, is crucial to property and most other things and I wonder if the installed location is as important or different between distros using the same package format?
As both Mandravia and SuSE subscribe to the FHStandard can the above assumption be made?
Regards -- ======================================================================== Hylton Conacher - Linux user # 229959 at http://counter.li.org Currently using SuSE 9.0 Professional with KDE 3.1 ========================================================================
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
I'd have thought that by installing via YaST they would be installed in the correct places according to SuSE. You'd just need to add the download point as a source and go from there as normal. I could be wrong but I'd be happy to hear from other more experienced Linux users on this one. -- Take care. Kevan Farmer 34 Hill Street Cheslyn Hay Staffordshire WS6 7HR
On 5/9/05, Hylton Conacher (ZR1HPC) <hylton@global.co.za> wrote:
Is it possible to use those RPM's via YaST and still have them install in the correct SuSE locations or as it might be a Mandrake RPM it will install in locations Mandrake would have.
I'd have thought that by installing via YaST they would be installed in the correct places according to SuSE. The places of installation (i.e. directories tree for the files) is a
Kevanf1 wrote: part of the rpm. Yast does nothing magical to redistribute the files to SuSE's tree, so it would solely depend on the particular rpm and how it was packaged -- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Registered Linux user 231871
On 5/9/05, Joe Morris (NTM) <Joe_Morris@ntm.org> wrote:
On 5/9/05, Hylton Conacher (ZR1HPC) <hylton@global.co.za> wrote:
Is it possible to use those RPM's via YaST and still have them install in the correct SuSE locations or as it might be a Mandrake RPM it will install in locations Mandrake would have.
I'd have thought that by installing via YaST they would be installed in the correct places according to SuSE. The places of installation (i.e. directories tree for the files) is a
Kevanf1 wrote: part of the rpm. Yast does nothing magical to redistribute the files to SuSE's tree, so it would solely depend on the particular rpm and how it was packaged -- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Registered Linux user 231871
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
There you go, proof that I can learn something new everyday :-) Cheers for that, I honestly thought YaST did the allocation. -- Take care. Kevan Farmer 34 Hill Street Cheslyn Hay Staffordshire WS6 7HR
On Mon, 2005-05-09 at 10:12 +0200, Hylton Conacher (ZR1HPC) wrote:
I have a working SuSE 9.0 system which I use. All of the packages are off the 9.0 CD's and I 'prefer' to only use SuSE compiled RPM's as then I know files are going to be installed in the correct place, wherever that may be. From time to time I see software package updates, either on CD or the web but they are for another distro ie Mandrake and perhaps others.
Is it possible to use those RPM's via YaST and still have them install in the correct SuSE locations or as it might be a Mandrake RPM it will install in locations Mandrake would have.
Basically the question revolves around location, location, location. Being in the right place at the right time, is crucial to property and most other things and I wonder if the installed location is as important or different between distros using the same package format?
As both Mandravia and SuSE subscribe to the FHStandard can the above assumption be made?
Packages will be installed according to how they were added to the RPM. If unsure just use less to look at the rpm and see where they will go. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
I have a working SuSE 9.0 system which I use. All of the packages are off the 9.0 CD's and I 'prefer' to only use SuSE compiled RPM's as then I know files are going to be installed in the correct place, wherever that may be. From time to time I see software package updates, either on CD or the web but they are for another distro ie Mandrake and perhaps others.
Is it possible to use those RPM's via YaST and still have them install in the correct SuSE locations or as it might be a Mandrake RPM it will install in locations Mandrake would have.
Basically the question revolves around location, location, location. Being in the right place at the right time, is crucial to property and most other things and I wonder if the installed location is as important or different between distros using the same package format?
As both Mandravia and SuSE subscribe to the FHStandard can the above assumption be made?
Regards In the good old days, you could grab a rpm of deb package and install it on any other distro, not so now. The FHS allows quite a bit, it's more a guide to how the filesystem should be set up rather than a cast iron guide to where people install stuff or what features the include, e.g /opt and /usr/local/bin are there in Mandriva, both empty. When you look into it, you can see the pain it causes if you are a developer, you must build separate packages for each distro unless you use static linking. The Connectiva packages used to be compatible with SuSE, checking the Mandriva LE 2005 (obviously old Mandrake), everything seems to go in /usr, e.g all the kde binaries are in /usr/bin and the libraries in /usr/lib. The Mandriva stuff should still work on SuSE providing a
Hylton Conacher (ZR1HPC) wrote: particular app doesn't depend on something not compiled into the SuSE libraries or compiled with different libs.... e.g.. barrabas:/ftp/May05 # rpm -ivh /media/cdrom/media/main3/cooledit-3.17.7-8mdk.i586.rpm warning: /media/cdrom/media/main3/cooledit-3.17.7-8mdk.i586.rpm: V3 DSA signature: NOKEY, key ID 70771ff3 error: Failed dependencies: pythonlib is needed by cooledit-3.17.7-8mdk libCw1 = 3.17.7-8mdk is needed by cooledit-3.17.7-8mdk libCw.so.1 is needed by cooledit-3.17.7-8mdk The Mandriva package does not include libCw1, on SuSE 9.3 cooledit built from sources and made into an rpm with checkinstall includes libCw1 and doesn't depend on pythonlib - both apps have the same appearance. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Keen licensed Private Pilot Retired IBM Mainframes and Sun Servers Tech Support Specialist Microsoft Windows Free Zone - Linux for all Computing Tasks
On Monday 09 May 2005 11:12, Hylton Conacher (ZR1HPC) wrote:
Basically the question revolves around location, location, location.
But not the only important thing. Another is libraries. A foreign package might expect to have this library and that, version X or Y, and placed here of there. If the package is a simple one, without many dependencies, you can install it on SUSE and not worry about location. Obviously, updates to that package will have to be done manually, too. However, in the case of a complex piece of software, you won't have much success. That is you won't break anything beyond repair (rpm --erase), but your software might not work. Examples of what won't work easily, from foreign packages: evolution, apache2, mysql. However, other generic rpms like acroread, BitTorrent, ICAClient will work. Except many of them won't create menu entries in the right places (if at all).
On Tuesday 10 May 2005 05:04, Silviu Marin-Caea wrote:
On Monday 09 May 2005 11:12, Hylton Conacher (ZR1HPC) wrote:
Basically the question revolves around location, location, location.
But not the only important thing.
Another is libraries.
However, other generic rpms like acroread, BitTorrent, ICAClient will work. Except many of them won't create menu entries in the right places (if at all).
Hi, Doesn't LSB (Linux Standard Base) compliance figure into this question too? PeterB
On Tue, 2005-05-10 at 08:29 -0500, Peter B Van Campen wrote:
On Tuesday 10 May 2005 05:04, Silviu Marin-Caea wrote:
On Monday 09 May 2005 11:12, Hylton Conacher (ZR1HPC) wrote:
Basically the question revolves around location, location, location.
But not the only important thing.
Another is libraries.
However, other generic rpms like acroread, BitTorrent, ICAClient will work. Except many of them won't create menu entries in the right places (if at all).
Hi,
Doesn't LSB (Linux Standard Base) compliance figure into this question too?
PeterB
Yes, that was the whole purpose but try and get everyone to agree on what is the standard location. Just one more reason holding back linux from being more widespread. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
Ken Schneider wrote:
On Tue, 2005-05-10 at 08:29 -0500, Peter B Van Campen wrote:
On Tuesday 10 May 2005 05:04, Silviu Marin-Caea wrote:
On Monday 09 May 2005 11:12, Hylton Conacher (ZR1HPC) wrote:
Basically the question revolves around location, location, location.
But not the only important thing.
Another is libraries.
However, other generic rpms like acroread, BitTorrent, ICAClient will work. Except many of them won't create menu entries in the right places (if at all).
Hi,
Doesn't LSB (Linux Standard Base) compliance figure into this question too?
PeterB
Yes, that was the whole purpose but try and get everyone to agree on what is the standard location. Just one more reason holding back linux from being more widespread.
I very much doubt you'd get the various distros to agree a standard way of doing things, UnitedLinux was the one hope, but now it's every distro for itself, trying to relive the Unix experience for sure -- lemmings are destined to forever walk off cliffs and die. The kernel is the one strand that's stopping a proper set of forks. What we need is a set of interoperability checks and certification that a standard application set will run across all distros and a distro is not shipped until it's certified. Some weeks ago I downloaded a RedHat/Fedora source rpm which built and installed fine on SuSE 9.2, it just didn't run. You also saw my example of trying to install the Mandriva version of cooledit on SuSE 9.3. Look at http://www.skype.com/products/skype/linux/ to see the nonsense that Skype has to go through for each distro, at least a number of distros had the good sense to base themselves on Debian, possibly one reason why Munich went Debian after SuSE/IBM had done all the hard work. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Keen licensed Private Pilot Retired IBM Mainframes and Sun Servers Tech Support Specialist Microsoft Windows Free Zone - Linux for all Computing Tasks
On 5/10/05, Sid Boyce <sboyce@blueyonder.co.uk> wrote:
I very much doubt you'd get the various distros to agree a standard way of doing things, UnitedLinux was the one hope, but now it's every distro for itself, trying to relive the Unix experience for sure -- lemmings are destined to forever walk off cliffs and die. The kernel is the one strand that's stopping a proper set of forks. What we need is a set of interoperability checks and certification that a standard application set will run across all distros and a distro is not shipped until it's certified. Some weeks ago I downloaded a RedHat/Fedora source rpm which built and installed fine on SuSE 9.2, it just didn't run. You also saw my example of trying to install the Mandriva version of cooledit on SuSE 9.3. Look at http://www.skype.com/products/skype/linux/ to see the nonsense that Skype has to go through for each distro, at least a number of distros had the good sense to base themselves on Debian, possibly one reason why Munich went Debian after SuSE/IBM had done all the hard work. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Keen licensed Private Pilot Retired IBM Mainframes and Sun Servers Tech Support Specialist Microsoft Windows Free Zone - Linux for all Computing Tasks
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
It must also have the effect of stopping hardware manufacturers from producing drivers for Linux. This is something that I hadn't really thought of before but it makes a bit of sense. But, just to contradict myself the same manufacturers have had to produce very different drivers for the various flavours of M$ software over the years. Some have drivers for 9* series, Win2k and XP. I'm sure Linux drivers would not have to be that much different. Or am I wrong in this assumption? -- Take care. Kevan Farmer 34 Hill Street Cheslyn Hay Staffordshire WS6 7HR
Kevanf1 wrote:
On 5/10/05, Sid Boyce <sboyce@blueyonder.co.uk> wrote:
I very much doubt you'd get the various distros to agree a standard way of doing things, UnitedLinux was the one hope, but now it's every distro for itself, trying to relive the Unix experience for sure -- lemmings are destined to forever walk off cliffs and die. The kernel is the one strand that's stopping a proper set of forks. What we need is a set of interoperability checks and certification that a standard application set will run across all distros and a distro is not shipped until it's certified. Some weeks ago I downloaded a RedHat/Fedora source rpm which built and installed fine on SuSE 9.2, it just didn't run. You also saw my example of trying to install the Mandriva version of cooledit on SuSE 9.3. Look at http://www.skype.com/products/skype/linux/ to see the nonsense that Skype has to go through for each distro, at least a number of distros had the good sense to base themselves on Debian, possibly one reason why Munich went Debian after SuSE/IBM had done all the hard work. Regards Sid. --
It must also have the effect of stopping hardware manufacturers from producing drivers for Linux. This is something that I hadn't really thought of before but it makes a bit of sense. But, just to contradict myself the same manufacturers have had to produce very different drivers for the various flavours of M$ software over the years. Some have drivers for 9* series, Win2k and XP. I'm sure Linux drivers would not have to be that much different. Or am I wrong in this assumption?
The drivers problem is different as they are an adjunct to the kernel. The real problem there is that the manufacturers are afraid they would be letting too many secrets out of the bag so that a competitor could use their code to build a similar product lots cheaper and easier, they do the work and someone else uses it to put them out of business. Companies like NVidia have opted for a half way house that delivers useful drivers for free use with Linux and at the same time protecting their hardware development secrets, to me, an acceptible compromise. Some others are not prepared to go that far and would like to contribute binary only drivers a-la-Windows which break with at times just a slight change in the kernel. Binary-only drivers are also disliked becuase the kernel developers are unable to troubleshoot any possible problems that those drivers may introduce or kernel problems that are exposed by such drivers. When manufacturers have been willing to disclose their driver secrets, the kernel developers are able to make changes with them in mind so that things continue to work and the kernel is not "tainted", if you submit a kernel problem with say, NVidia video driver module active, the kernel reports "tainted", so they won't look at it. What I do in these cases is to use "nv" instead of "nvidia" in /etc/X11/xorg.conf and send them the untainted report. Overall, we are not too badly off with drivers as thankfully the range of hardware to choose from sees to that, also many manufacturers are using essentially the same hardware in their products and the problem seems to be of less significance now. Just last week I came across an ORIGO 10/100 Fast Ethernet card I had around for years that I never got going when I bought it, the chip says Davicom, now I popped it into the Mandriva box and it's recognised, driver loaded and configured. When I bought it, DEC Tulip cards were common and recognised, but this one wasn't. 00:09.0 Ethernet controller: Davicom Semiconductor, Inc. 21x4x DEC-Tulip compatible 10/100 Ethernet (rev 40) Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Keen licensed Private Pilot Retired IBM Mainframes and Sun Servers Tech Support Specialist Microsoft Windows Free Zone - Linux for all Computing Tasks
On Tue, 10 May 2005 23:08:42 +0100 Sid Boyce <sboyce@blueyonder.co.uk> wrote:
Look at http://www.skype.com/products/skype/linux/ to see the nonsense that Skype has to go through for each distro, at least a number of distros had the good sense to base themselves on Debian, possibly one reason why Munich went Debian after SuSE/IBM had done all the hard work.
I suspect you're on the money there, Sid. At least Debian has a constant structure, and a rock-solid one at that. If it didn't take so much time to set up as I want it ...................... Terence
On Wednesday 11 May 2005 22:27, Terence McCarthy wrote:
On Tue, 10 May 2005 23:08:42 +0100
Sid Boyce <sboyce@blueyonder.co.uk> wrote:
Look at http://www.skype.com/products/skype/linux/ to see the nonsense that Skype has to go through for each distro, at least a number of distros had the good sense to base themselves on Debian, possibly one reason why Munich went Debian after SuSE/IBM had done all the hard work.
I suspect you're on the money there, Sid. At least Debian has a constant structure, and a rock-solid one at that.
What are you guys talking about? "SUSE, RedHat and Mandrake et al. can't agree where to keep things, therefore Debian is better because Debian keeps things in the same place as Debian"??? The reason skype and opera needs to maintain separate versions is because it's written in c++. Blame the gcc project instead of the distros. Debian is stable because Debian never updates anything unless the project leader retires, or something. I hope you're not saying we should never update libraries ever But I do agree that the gcc c++ project isn't the best run project in the world
On Tuesday 10 May 2005 16:29, Peter B Van Campen wrote:
However, other generic rpms like acroread, BitTorrent, ICAClient will work. Except many of them won't create menu entries in the right places (if at all).
Hi,
Doesn't LSB (Linux Standard Base) compliance figure into this question too?
Yes, it does. You have good chances to get a foreign .rpm running on a _comparable_ version from SUSE. That is if the other distro has the same versions of libraries. If it's older of newer, then chances diminish. But don't compare distro versions, compare component versions. Like kernel, glibc, kde, gnome. And about the menu entries, there's XDG, a relatively new standard promoted by freedesktop.org that KDE, Gnome and Window Maker have begun using. In all this picture that is really going in the right direction, contrary to what some of you guys think, there is another element: software "ported" from Windows, by Windows-loving companies, that started to do some stuff on Linux, because of market pressure. An experienced Linux-er can easily tell when a rpm or .tar.gz is made by one of those companies. They do it "the Windows way", they don't always know about the Linux standards. Now, there's no need to be mean to them :-) after all they have shown goodwill, but they sure do need to be told how things are supposed to be done right in Linux.
Silviu Marin-Caea wrote:
On Tuesday 10 May 2005 16:29, Peter B Van Campen wrote:
However, other generic rpms like acroread, BitTorrent, ICAClient will work. Except many of them won't create menu entries in the right places (if at all).
Hi,
Doesn't LSB (Linux Standard Base) compliance figure into this question too?
Yes, it does. You have good chances to get a foreign .rpm running on a _comparable_ version from SUSE. That is if the other distro has the same versions of libraries. If it's older of newer, then chances diminish.
But don't compare distro versions, compare component versions. Like kernel, glibc, kde, gnome.
Mandrake/Mandriva versions are always close to SuSE in the main components, but as I earlier demonstrated, they will alter the sources to suit themselves, so the equivalent versions of a package won't necessarily install.
And about the menu entries, there's XDG, a relatively new standard promoted by freedesktop.org that KDE, Gnome and Window Maker have begun using.
In all this picture that is really going in the right direction, contrary to what some of you guys think, there is another element: software "ported" from Windows, by Windows-loving companies, that started to do some stuff on Linux, because of market pressure.
An experienced Linux-er can easily tell when a rpm or .tar.gz is made by one of those companies. They do it "the Windows way", they don't always know about the Linux standards. Now, there's no need to be mean to them :-) after all they have shown goodwill, but they sure do need to be told how things are supposed to be done right in Linux.
An actual example where you hit problems building from source ..... svxlink fails to build on SuSE because the gsm library used by SuSE has its origin in germany and it's not the one used by the other distros, so you have to build the more widely used and generic libgsm in order to build and run that package on SuSE. The developer at one stage adopted my changes, including libgsm, so it built on all distros including SuSE, but the latest version has rolled back the libgsm change, he was a bit dismissive, so I had to send him a copy of my original email as reminder of what was said back then. There is a real problem, hence the startup of http://rpmforge.net which aims initially to provide spec files for building standard packages for all distros, deliver packages for each distro and hopefully arrive at a stage where an agnostic spec file can be generated, suited to all distros and more likely rpms that are distro agnostic. The source files are more often than not capable of being built on any distro, but the distros at times do strange things that ensure their source versions won't build on another distro. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Keen licensed Private Pilot Retired IBM Mainframes and Sun Servers Tech Support Specialist Microsoft Windows Free Zone - Linux for all Computing Tasks
I have a working SuSE 9.0 system which I use. All of the packages are off the 9.0 CD's and I 'prefer' to only use SuSE compiled RPM's as then I know files are going to be installed in the correct place, wherever that may be. From time to time I see software package updates, either on CD or the web but they are for another distro ie Mandrake and perhaps others.
Is it possible to use those RPM's via YaST and still have them install in the correct SuSE locations or as it might be a Mandrake RPM it will install in locations Mandrake would have. Thanks to all for the extended response. Basically we can say as SuSians
Hylton Conacher (ZR1HPC) wrote: that whilst it may be possible to install other distro RPM's on our system, or even Debian pkgs via Alien, the end result could be a VERY big mess as each distro would install the package in its own place thinking that other apps/dependencies are in certain places when in actual fact they may not be. So, we have ruled out using other's RPMs/Pkgs but what about compiling those packages from source into a SuSE RPM and then installing it? Surely Linux drivers/modules could be handled the same way ie Doesn't open source mean the source code is available? Is the RedCarpet app a partial solution to graphically compiling and installing source code from ANY Linux distro? Regards again -- ======================================================================== Hylton Conacher - Linux user # 229959 at http://counter.li.org Currently using SuSE 9.0 Professional with KDE 3.1 ========================================================================
On Sunday 15 May 2005 12:01, Hylton Conacher (ZR1HPC) wrote:
Thanks to all for the extended response. Basically we can say as SuSians that whilst it may be possible to install other distro RPM's on our system, or even Debian pkgs via Alien, the end result could be a VERY big mess as each distro would install the package in its own place thinking that other apps/dependencies are in certain places when in actual fact they may not be.
I disagree that it would be a very big mess. Most packages should install nicely and run. dependencies and apps usually don't have to be in a particular place, that's what paths are for. You might have problems with KDE apps and other things that have a hard coded path to configuration files (run a KDE app in suse and it will expect to find config files in /etc/opt/kde3, while a red hat app will install it elsewhere) but for most things it should work fine.
So, we have ruled out using other's RPMs/Pkgs but what about compiling those packages from source into a SuSE RPM and then installing it?
Sure, that usually works fine, as long as you have all the development libraries installed that you need to build it. You may have to tweak the spec file a bit though, to change hard coded paths like --prefix
Surely Linux drivers/modules could be handled the same way ie Doesn't open source mean the source code is available?
In a way. It means the people who have access to the binaries also have access to the source and can do certain things with it without asking permission or paying for it.
Is the RedCarpet app a partial solution to graphically compiling and installing source code from ANY Linux distro?
Nope. At least not yet. It is primarily a tool for distributing rpms that have already been compiled. The compiling part has to be done elsewhere
Anders Johansson wrote:
On Sunday 15 May 2005 12:01, Hylton Conacher (ZR1HPC) wrote:
Thanks to all for the extended response. Basically we can say as SuSians that whilst it may be possible to install other distro RPM's on our system, or even Debian pkgs via Alien, the end result could be a VERY big mess as each distro would install the package in its own place thinking that other apps/dependencies are in certain places when in actual fact they may not be.
I disagree that it would be a very big mess. Most packages should install nicely and run. dependencies and apps usually don't have to be in a particular place, that's what paths are for.
You might have problems with KDE apps and other things that have a hard coded path to configuration files (run a KDE app in suse and it will expect to find config files in /etc/opt/kde3, while a red hat app will install it elsewhere) but for most things it should work fine.
So, we have ruled out using other's RPMs/Pkgs but what about compiling those packages from source into a SuSE RPM and then installing it?
Sure, that usually works fine, as long as you have all the development libraries installed that you need to build it.
You may have to tweak the spec file a bit though, to change hard coded paths like --prefix
Surely Linux drivers/modules could be handled the same way ie Doesn't open source mean the source code is available?
In a way. It means the people who have access to the binaries also have access to the source and can do certain things with it without asking permission or paying for it.
Is the RedCarpet app a partial solution to graphically compiling and installing source code from ANY Linux distro?
Nope. At least not yet. It is primarily a tool for distributing rpms that have already been compiled. The compiling part has to be done elsewhere
Use alien to break out the stuff, edit the spec file, etc., etc. It's not a straightforward task, I've just tried 3 src.rpm packages on SuSE 9.3, none build. It would be simpler to grab src.tar.bz2 etc. files and build them on Mandrake, SuSE or whatever distro separately, checkinstall to generate the RPM for each. I've tried one Fedora package that built and installed fine, but didn't run, I've also had problems building other RH/Fedora src.rpm packages on SuSE, I've also been able to download RH packages and libraries that get installed in places other than where SuSE puts them and get them running, at times having to use a bash script with LD_PRELOAD. I'd only ever attempt it if the package was only available for the one distro, hoping I get lucky. The distros mess with the virgin sources too much. There are real compatibilty problems between distros, that why you see ISV's generating separate packages. The same mindset that crippled Unix is still alive, well and practiced - remember, human stupidity is infinite, you'll find it right in every Linux distro, except that the kernel and vanilla sources sit above it all, thankfully. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Keen licensed Private Pilot Retired IBM Mainframes and Sun Servers Tech Support Specialist Microsoft Windows Free Zone - Linux for all Computing Tasks
On Sunday 15 May 2005 22:19, Sid Boyce wrote:
There are real compatibilty problems between distros, that why you see ISV's generating separate packages.
Very few. Look at opera and skype. The *only* difference between the versions is which version of libstdc++ is used. Or look at mozilla, openoffice or eclipse. They aren't written in c++ so there you have one size fits all. 99% of all compatibility problems are just bad packaging
On Sunday 15 May 2005 22:25, Anders Johansson wrote:
Or look at mozilla, openoffice or eclipse. They aren't written in c++ so there you have one size fits all.
That was exceptionally silly, wasn't it. They are written in c++ and you do have the libstdc++ problems with them, for example the java plugin problem from a few years ago. But anyway, the point is that we don't have the unix situation, we just rely on the gcc c++ project way too much (as far as I'm aware, other compilers have had a stable C++ ABI for some time, so this isn't something that's "needed for progress", the usual excuse for not having a stable kernel driver ABI)
participants (9)
-
Anders Johansson -
Hylton Conacher (ZR1HPC) -
Joe Morris (NTM) -
Ken Schneider -
Kevanf1 -
Peter B Van Campen -
Sid Boyce -
Silviu Marin-Caea -
Terence McCarthy