On Mon, 2004-11-29 at 20:26 +0800, John Summerfield wrote: > On Monday 29 November 2004 19:07, Axel Thimm wrote: > > Or let me rephrase the problem, why do some people insist that > > replacing packages is bad? > > I used to be a systems programmer, a member of a team responsible for maintain > the system software on multisquillion dollar IBM mainframes. > > One of the things I learned there is that every step from the standard way of > doing things brings more headaches. > > Whenever we customised IBM's software (and we did), we needed a plan to ensure > a smooth transition to the next IBM release. > > Whenever we installed software from another vendor (and we did), we needed a > plan to ensure that the different sets of software worked together smoothly, > and to be sure we could update smoothly to the next releases of each. > > There is a reason RH highlights that you cannot upgrade a system with Ximian's > Gnome packages in place: Ximian's packages are different (why else would > anyone want them) and conflict with what RH provides. I expect no less. > Exactly, and if you are writing or packaging an application to run on the base os it behooves you to make certain your package does not impair the standard distribution, or at least document in detail the changes it makes. > If I want to package software for RHEL or Fedora Core I will target a specific > environment, most probably a standard install with no third-party extras. > What else _can_ I do? Unless I'm enhancing one of those extras of course. > It's up to administrators (often the users) to ensure that they don't have > conflicting packages, of they do, to have a plan to work around the > difficulties that will arise. > And for packagers such as Ximian above, they have to expect and plan for problems in updates whenever the user moves to a newer release of the platform they are running on. Currently, IBM for example, has customers that are stuck on a version of AIX that is not even supported by IBM at this time because of age, simply due to the application developer's delay/failure in providing package updates to support operation on the newer OS version. > I will, of course, expect you to read the documentation I provide, before > installing and maybe before acquiring the sotware. > And this is one problem with third party packagers. Non-standard naming/packaging practices and the extent by which some modify the core OS make compatibility choices difficult. Total lack of documentation on the changes and compatibilities make it hard to know what is right, so using a site where everything is known to "just work" without breaking something else is a big factor. With open source software anyone is free to make the modifications they choose, and on the other side, *users* are free to select the packages and repository they choose as well. I myself choose standardization and less intrusive applications so I have gone with Dag and ATrpms repositories since they have indicated they want to cooperate and standardize the procedure. Fedora.US and Livna have lost my vote here (although I may use some of their packages as long as it doesn't break something else). Recently I tried to do a yum update (when I had the fedora.us repository enabled) and it failed because of dependencies on several libraries that WERE installed. It seemed the packages selected from fedora.us were trying to remove some libraries that were required by installed packages. I removed fedora.us from my list of repositories and the update went flawlessly after that. > -- > Cheers > John >
