On Thursday 31 August 2006 17:57, Jeff Rollin wrote:

On 31/08/06, rich wrote:

...

I wanted to run Yahoo Messenger on Suse 10.1 but the Yahoo web site provides packages for other distros than Suse. I tried to install Yahoo Messenger anyway, and miracle, it worked. It brings to mind the question of what requirements a package must meet to be able to run on Suse. How can I tell a non-Suse package will be able to run on Suse (10.1) successfully?

I really should have tried to find the link before posting this, but I once read that one user had no trouble installing rpms on Debian if he used the --nodeps option. So to find out if a given package will work, I would just try installing it. In my experience if it will fail, rpm won't let you install it anyhow.

Using '--nodeps' isn't a good idea unless you know exactly what you're doing. It's better to run a trial, first: # rpm -ihv packagename.rpm --test This runs through the installation without actually writing anything into the filesystem. It will report any errors it encounters concerning conflicts and/or missing dependencies. 'man rpm' for more options. You can also 'navigate into' an .rpm file with Konqueror to review which files would be installed, including full paths, so you can check for odd/different ('non-SUSE' standard) locations and/or existing items that would be overwritten. hth & regards, Carl

On Thursday 31 August 2006 19:21, Mike McQueen wrote:

On Thursday 31 August 2006 17:33, Carl Hartung wrote:

...

Using '--nodeps' isn't a good idea unless you know exactly what you're doing. It's better to run a trial, first:

# rpm -ihv packagename.rpm --test

If a person was to install an RPM with nodeps would YaST or ZMD then complain going forward anytime that you wanted to use it for package management (assuming there were some deps which were ignored), or would YaST simply accept the package with the conditions you passed it and not consider it a breakage?

It depends on whether or not the package actually introduces conflicts or has unmet dependencies. If there's nothing to 'complain' about, I don't imagine you will see anything unusual the next time you run YaST2. It *does* properly register the installed files in rpm's database, but I don't know off-hand if it sets the package's 'don't complain' flag in the process. In any event, in YaST's 'Software Management' module somewhere in the top menu, exists an option to reset previously ignored conflicts. That would be worth checking out. Think of the '--nodep' flag as something a developer might use to temporarily override normal protections to quickly test a code change or one that an 'expert user' might use during a series of out-of-sequence, interrupted or incremental changes. Carl

On Thursday 31 August 2006 20:17, Mike McQueen wrote:

Well, I knew from earlier use of an apt-based distro that if you forced in a package by ignoring predefined deps that it basically made the package manager unusable until the unresovled dep issue was resovled. I was not aware of being able to set or reset ignored conflicts in YaST. If this could be done on a per package basis then that would present a different (though probably not recommended) way to maintain these type of packages.

The underlying package management database engine is rpm, so you can accomplish all the same things via CLI as you can with the various GUIs. Also, I think '--nodep' is a subset/variant of '--force' in that it only suppresses dependency checks. I don't think it suppresses *all* errors (as in outright conflicts.) I believe both set the 'ignore' flag, though, enabling you to continue operating the package manager as you set things right... assuming, of course, whatever you've been mucking around with hasn't destabilized or crashed the system ;-) I make a determined effort to keep my rpm database 'clean' by avoiding these 'games' whenever possible. I've used them before... but very, very sparingly... and not ended my session without bringing the system back to consistency (takes planning.) Carl

On Thursday 31 August 2006 13:53, rich wrote:

...

It brings to mind the question of what requirements a package must meet to be able to run on Suse. How can I tell a non-Suse package will be able to run on Suse (10.1) successfully?

Many times you can just try to install it, and if your machines meet all the pre-requsits it will work.

However I've had to back out more than one RPM because it tried to use things that apparently even the developer didn't know he was using. In defence of the developers who provide this fine distro, it is not

John Andersen wrote: things that the developer disn't know he was using. It is about location, location and location. Location of the installed app ie in usr or somewhere different to what SuSE expects. Location of the dependencies, evenif there aren't any. The RPM file built for Suse knows in what directories to find what it needs. Install another distro RPM that expects to find the dependencies in a different directory to the SuSE standard and you have a SNAFU ie dependant packages are in /home as opposed to the SuSE way of /lib. Rewriting the config file is possible as the source is available but MANY past Windows users, myself included, would not know where to begin in rewiting a .config file so that the none SuSE app works, as it should, with SuSE. hth -- ======================================================================== Currently using SuSE 9.2 Professional with KDE and Mozilla 1.7.2 Linux user # 229959 at http://counter.li.org ========================================================================

On Sunday 10 September 2006 17:30, Peter Van Lone wrote:

I *suspect* that SUSE has more variance from the "regular" than other RPM distros ... is my suspicion correct?

At any rate, it would be useful to have a Red Hat vs SUSE path defaults comparison.

The base line to be compared with for any distro should be the Linux Standards Base (http://lsb.freestandards.org/) and the File system Hierarchy Standard (http://www.pathname.com/fhs/) Those are the targets to aim for. Some distros historically have aimed for "red hat compatibility", but the above two standards are the only ones that should be called "regular". As far as I know, all major distros today (even Debian) are working towards implementing them The only major difference that I'm aware of today is where distros place gnome and kde. SUSE has them in /opt, others in /usr, but from 10.2, SUSE will also move towards /usr

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-09-10 at 11:23 -0800, John Andersen wrote:

So you are saying RPM looks for these dependency files on the disk in specific places rather than looking at the rpm database to see if they were installed?

See Philipp's message. The rpm command (and yast and the rest) looks only at the rpm database for dependencies. It is the program you are installing who may try to find a library at a different place depending on the distro - in fact, depending on the person that compiled it. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFBTCFtTMYHG2NR9URAj/SAJ9Y5GhalC/OGXif+oEQtLI3KDj63QCffZ72 atboKihfGAVA5b5md3GPJkk= =mhDw -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-09-11 at 02:05 -0800, John Andersen wrote:

But had you actually read my post you would have seen I already knew this.....

I did read them. AFAIK, if you were asking about it, you didn't know or were unsure. Otherwise, you wouldn't be asking... or your wording wasn't clear enough on this. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFBUB6tTMYHG2NR9URAhxbAJ9sfRQimwocH7Zk+igC1OnHff85zwCglSIh Qj8c2pPkMw/ETXrFoQ+OUdY= =b94X -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-09-11 at 09:50 -0800, John Andersen wrote:

I was asking the OP if that was what he meant to say. Because it was so obviously wrong.

Ok :-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFBa7MtTMYHG2NR9URAut0AJ9olEUZZN8E31zoaSa4rLwT+NsAfQCfUwIp Wim8zY2p4LBtiQaHh4LPtzY= =sSAM -----END PGP SIGNATURE-----