| | 1 | === Why Do we provide packages only for certain distributions and systems? === |
| | 2 | |
| | 3 | As the upstream authors, our primary distribution method is naturally |
| | 4 | the source itself in tar.gz and tar.bz2 form. Our responsibility ends |
| | 5 | when we release the tarball. |
| | 6 | |
| | 7 | As a convience, an extra, we provide binary installers where we have |
| | 8 | developers able and willing to do so. Thus we have developers with a |
| | 9 | significant number of redhat and fedora machines or chroot environments. |
| | 10 | These developers create the various rpm packages you see. |
| | 11 | |
| | 12 | While we have a few developers using debian systems, the debian package |
| | 13 | maintainers have historically worked closely with us and provided timely |
| | 14 | updates to the official packages. There has been no need on our part to |
| | 15 | create packages for debian unstable, and no desire on our part to try to |
| | 16 | create backport packages to debian testing or stable. |
| | 17 | |
| | 18 | We have no developers using Slack, and furthermore, several of us |
| | 19 | actively dislike that distribution for its history of broken installs, |
| | 20 | as well as for its non-existant package management. You cannot create |
| | 21 | true packages for Slack. |
| | 22 | |
| | 23 | We have no developers using arch, SuSE, or any other distribution. |
| | 24 | |
| | 25 | We provide Windows installers, bundled with Gtk+ and some other dependencies, in recognition of the fact that these dependencies are likely to be unavailable on most Windows machines, and that most of our Windows users do not have the experience necessary to find or build them on their own. |
| | 26 | |
| | 27 | While the same holds true of MacOSX, we do not provide OSX packages, prefering to point users to Adiumx, because Pidgin, as an X11 application, will never integrate into an OSX user's environment as cleanly as a native program can. Ideally the winpidgin version will be replaced by a more native Windows UI at some point, and we will be able to stop producing the Windows installers as well. |
| | 28 | |
| | 29 | Many people have asked about providing packages for inclusion on the downloads page. This seems like a reasonable solution to the fact that we simply do not have the resources in either machines, diskspace, or time, to build packages for every system type and distribution out there. It is, in fact, a solution that we tried in the past. Unfortunately, it was abused, and packages were posted that, unbeknownst to us, contained unauthorized patches which introduced bugs. In light of the fact that we are unable to prevent such abuse from happening again, we do not accept or post packages that we do not build. |
| | 30 | |
| | 31 | As I said, the fact that we provide binary installers at all should be |
| | 32 | viewed rather as an extra, as the primary source for packages should |
| | 33 | always be your distro. When you get packages for your distro, you have |
| | 34 | a level of assurance that this package will not break unrelated services |
| | 35 | or programs that cannot exist when getting 3rd party packages from us, |
| | 36 | or from any other source. Additionally, the distros often apply patches |
| | 37 | to gaim, and while sometimes these patches cause problems, they also |
| | 38 | often fix bugs that were discovered after the release. |
