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.

... so there is no reason to revert. Package managers are not designed to solve the problem of a "user needs a simple means to install software": they are designed to help a competent administrator solve the problem of "installing and upgrading uncoordinated software releases".

Uniform version naming would be a mistake: each development effort picks the naming scheme most expedient in development, often depending on the tools in use, which are not the same because not all projects are the same. Users would benefit from uniform naming, but they do not contribute to development and as such their needs carry little weight; customers paying for a distribution might get uniform naming orchestrated by the distributor, of course, who might even find convenient to pay the upstream package developers and get the naming scheme changed, instead of fixing it every time. So the inefficiency of per-project-suboptimal version naming would be paid for by those who benefit from it.

Having a good view of multiple available versions may sound strange to people coming from the "latest version" syndrome, but Unix has a healthy tradition of "all versions work, you
need not the latest unless ..." and there are a number of
performance, security and usage tradeoff the competent administrator might want to explore when installing components.

With uncoordinated releases, conflicts happen (they also happen with InstallShield, by the way: it just happily ignores them and lets code malfunction when used - often in the guise of an obvious crash but I have seen my share of silently wrong results also). You cannot statically link a common component because there is a good chance it will not work: Unix has been providing for years the necessary library versioning infrastructure to have multiple versions of common components installed for exactly this reason.

The above does not mean current attempts at package management are perfect: it just means that reverting to Windows-like solutions would be a mistake. If the current solution is not satisfactory, the answer is not to provide a technologically inferior solution; users will have to wait until a solution which is easy to use and technically adequate appears.