Linked by Eugenia Loli on Sat 14th Sep 2002 22:44 UTC
SuSE, openSUSE From SuSE Linux 8.1 on, YaST2 comes with a new, powerful package manager. It supersedes the classic YaST2 single package selection and integrates the YaST Online Update (YOU) and post-installation add-on selection at the same time. It lays the foundation for supporting multiple installation sources like a traditional set of SuSE CDs, add-on product CDs, patch CDs, FTP servers or even local directories - all of which may contain software packages to install. Specially optimized versions were implemented for both graphical user interface (the YaST2 Qt UI) or text interface (the YaST2 NCurses UI), providing each type of user with the tool that best fits his needs. Read more for the commentary.
Permalink for comment
To read all comments associated with this story, please click here.
RE: Debian vs. Yast
by KPauls on Sun 15th Sep 2002 18:24 UTC

> There should be no conflicts. If there are, these should only
> happen in very few cases and they should be easily resolved.
> That would be a good OS design.

You should review Debian. ;->

There is (almost) NO amount of quality control or procedures that will allow 3rd parties to blindly submit packages (esp library packages).

This is complicated by the fact that binary-only commercial products often ship as RPM, but without enough release & quality control because Linux is a second-class citizen in the developer's world.

Debian avoids these problems by: 1) accepting packages to be maintained in the proper format by their developers, who can compile and link against the correct libraries and avoid dependency problems... and 2) by including many many more libraries in the standard distribution than any RPM based distro.

Never the less, Debian testing & unstable experience dependancy problems. Unless you run unstable and don't update for a few months you won't (to my experience) have an unresolvable dependancy.

Mac OS X's framework structure makes it much easier to maintain and link against multiple libraries. Their application configuration phillosophy (no registry, no dll's.. hmm NetInfoManager might be breaking that) and new tools (xml/dtd based configuration) prevent many other installation & maintinance problems.

Windows has only begun to avoid the old "DLL hell" (i.e. dependancy problems) that have existed for ages. When you uninstall a Windows program have you uninstalled all of the DLL's that came with it, or did you risk a missing dependancy? When you install a new application have you ever found that an old one doesn't work? Was it a DLL or a registry or an application extension problem? All of these are dependency conflicts.

Windows XP's rollback features promise to solve some of the DLL hell at the cost of disk space & complexity. Other standardizations (MSFT's ODBC api's, DirectX, Driver Certification) have avoided many dependancy conflicts, but some problems (file extension mapping, registry brokenness, broken links, uninstall leftovers) have existed for so long that developers simply work their way around them instead of developing new standards as gnu/linux tends to do (for example, package managers themselves, the menu and alternatives systems).