Context Navigation

Changes between Version 9 and Version 10 of WhyPackagesExist

Timestamp:: May 12, 2007, 2:17:53 PM (17 years ago)
Author:: nosnilmot
Comment:: --

Legend:

: Unmodified
: Added
: Removed
: Modified

WhyPackagesExist

-                      v9
+                      v10
 === Why Do we provide packages only for certain distributions and systems? ===
+As the upstream authors, our primary distribution method is naturally
+the source itself in tar.gz and tar.bz2 form.  Our responsibility ends
+when we release the tarball.
+As the upstream authors, our primary distribution method is naturally the source itself in tar.gz and tar.bz2 form.  Our responsibility ends when we release the tarball.
+As a convenience, an extra, we provide binary installers where we have
+developers able and willing to do so.  Thus we have developers with a
+significant number of Red Hat and Fedora machines or chroot environments.
+These developers create the various RPM packages you see.
+As a convenience, an extra, we provide binary installers where we have developers able and willing to do so.  Thus we have developers with a significant number of Red Hat and Fedora machines or chroot environments. These developers create the various RPM packages you see.
+While we have a few developers using Debian systems, the Debian package
+maintainers have historically worked closely with us and provided timely
+updates to the official packages.  There has been no need on our part to
+create packages for Debian unstable, and no desire on our part to try to
+create backport packages to Debian testing or stable.                                                                                                                                              The situation with Ubuntu is the same.
+While we have a few developers using Debian systems, the Debian package maintainers have historically worked closely with us and provided timely updates to the official packages.  There has been no need on our part to create packages for Debian unstable, and no desire on our part to try to create backport packages to Debian testing or stable. The situation with Ubuntu is the same.
+We have no developers using Slackware, and we do ''not'' support it, due
+to a history of problems which are caused or made unnecessarily difficult to solve
+by the fact that its package system does not support automatic dependency resolution.
+We also recommend that users do not attempt to compile Pidgin from source on
+Slackware, but instead use the packages provided by the Slackware team. If you
+insist on trying this out yourself, the only advice we can give you is to ask
+for help in #slackware on irc.freenode.org, or on the Slackware mailing lists.
+We have no developers using Slackware, and we do ''not'' support it, due to a history of problems which are caused or made unnecessarily difficult to solve by the fact that its package system does not support automatic dependency resolution.
+We also recommend that users do not attempt to compile Pidgin from source on Slackware, but instead use the packages provided by the Slackware team. If you insist on trying this out yourself, the only advice we can give you is to ask for help in #slackware on irc.freenode.org, or on the Slackware mailing lists.
 We have no developers using arch, SuSE, or any other distribution.
 …
 As I said, the fact that we provide binary installers at all should be                                                                                                                             viewed rather as an extra, as the primary source for packages should                                                                                                                               always be your distro.  When you get packages for your distro, you have                                                                                                                            a level of assurance that this package will not break unrelated services                                                                                                                           or programs that cannot exist when getting 3rd party packages from us,                                                                                                                             or from any other source.  Additionally, the distros often apply patches                                                                                                                           to Pidgin, and while sometimes these patches cause problems, they also                                                                                                                               often fix bugs that were discovered after the release.
+As I said, the fact that we provide binary installers at all should be viewed rather as an extra, as the primary source for packages should always be your distro.  When you get packages for your distro, you have a level of assurance that this package will not break unrelated services or programs that cannot exist when getting 3rd party packages from us,                                    or from any other source.  Additionally, the distros often apply patches                                              to Pidgin, and while sometimes these patches cause problems, they also                                                        often fix bugs that were discovered after the release.