On Sat, Apr 10, 2004 at 03:42:52AM +0200, Philipp Thomas wrote:
Phil Mocek <pmocek-list-suse@mocek.org> [Fri, 9 Apr 2004 13:10]:
The fact that bug tracking information for official SuSE packages is unavailable, even to paid users of ``SuSE Professional'', makes it very hard for me to recommend this distribution for use in a production environment.
For use in a production environment SUSE offers the "SUSE Linux Enterprise Server" which is maintained for five years and for which you buy the maintenance on a yearly basis.
By ``production environment'', I mean, loosely, a situation in which downtime or decreased functionality costs a business money -- as opposed to computers I have at home for personal use or ones on which a business tests out new software in an appropriate sandbox. This could be, say, a desktop machine in someone's office, or maybe a server that handles SMTP and IMAP. Are you saying that SuSE 9.0 Professional shouldn't be used in such a capacity? Isn't SLES the same thing with some extra software and a support contract? SLES starts out at what, $800 - $1000? What about those of us who don't need a support contract, but just reliable software and up-to-date documentation for it, including known problems with it?
SuSE should look to Debian or the various BSDs for examples of quality packaging and package management.
Bad example. Debian and the BSDs rely on volunteers and aren't commercial distributions so they don't have to account for where they spend money.
No, I think anyone who has used them would agree that Debian's and the BSDs' package management systems and related documentation are *shining* examples of quality packaging and package management. Does anybody here disagree? Whether or not that level of quality is financially feasible for a for-profit distribution is an unrelated issue. Even if it it would be too expensive for SuSE to attain that level of quality, it's still a good standard to strive for, and certainly worthy of comparison. Here's the world I'm coming from: All the official Debian releases are included in one repository which is mirrored in hundreds of locations around the world. There's a Web site where you can view just about any information you could need about any one of these packages. To install and upgrade software, you point your package manager at one or more of these official mirrors, and it pretty much handles the rest. People wanted this so badly in the RPM world, that Connectiva went off and ported Debian's APT tool for use with their RPM-based distribution. And now someone has made it work for SuSE as well (though SuSE won't support it). It's disheartening to install a piece of software -- from SuSE -- on a SuSE Linux machine, and have to discover for yourself that it doesn't work right -- even though SuSE has known for months that it doesn't work right -- then to be told, ``well, yeah, if you'd just searched through this list of all problems known for any package for any version of SuSE Linux, you would have noticed that there is a problem described in there that kind of sounds like your problem, and you'd have seen a suggestion for how to fix it -- it'll just take you a minute. Oh, and by the way, we won't be fixing this problem any time soon, so the next release of the package that caused your problem may or may not clobber the workaround that we've suggested -- and you won't know until after you install it.'' So if I have to rebuild this machine, or if I want to install the exact same software on a test machine, staging server or whatever, I need to keep not only the list of packages to install, but also my own a personal list of any of the fixes I came across and manually executed? That's a maintenance nightmare! It also breaks automated verification of installed packages' integrity. Is this really what everyone using SuSE Linux does? Or do you just take your chances on never needing to re-install things?
And once again: if bugs are too minor to warrant an official update, a workaround is usually published in our support database which is open for everyone. And in my eyes that suffices.
And once again, there is no way of knowing: * what problems have been identified for the latest release of SuSE package 'foo' * which known problems were solved for a given release (i.e., there's no changelog describing exactly what's different from the last release) So workarounds for minor bugs are *usually* published? And when they are, they're not even indexed by package? If I had known that the latest version of xntp has this problem that causes it's time drift tracking to fail, I would have never even *needed* to go digging through the sdb looking for problems describing similar symptoms to what I saw -- I would have performed the fix when I installed the xntp package. Does everyone see the difference here? The sdb is like a big bucket of symptoms and suggested remedies for SuSE Linux in general, even though SuSE Linux is broken down into individually-maintained, individually-installable, packages. If there's a mistake in the latest release of a particular package, isn't it reasonable for a customer to expect to be able to enter that package's name in a form on SuSE's Web site to find any and all of those problems known to SuSE which are specific to that package? In what world is that type of information not a necessity? Here's really the minimum that I expect: known problems for the latest release of each package, indexed by package name, and a changelog for each package describing which bugs were fixed for that release. Some other Linux distributions and BSD have been doing this for 10+ years. Does SuSE ever intend to publish such information? -- Phil Mocek