On 5/9/05, Joe Morris (NTM) wrote:

...

On 5/9/05, Hylton Conacher (ZR1HPC) 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 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

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

Kevanf1 wrote:

On 5/10/05, Sid Boyce 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 Wednesday 11 May 2005 22:27, Terence McCarthy wrote:

On Tue, 10 May 2005 23:08:42 +0100

Sid Boyce 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

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

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

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