4 ms·

> you write a Ruby package and now you have to support apt-get, yum, Gentoo, Arch, brew, MacPorts, etc wrong. that's the package maintainer's job. moreover, s

by Hello71 12y ago

> you write a Ruby package and now you have to support apt-get, yum, Gentoo, Arch, brew, MacPorts, etc wrong. that's the package maintainer's job. moreover, sensible package management systems have templates or libraries (eclasses in Gentoo) to properly handle all kinds of packages. all we ask for is that developers don't actively break package management by bundling everything as is done here.

voltagex_ 12y ago
Ir seems like there is often a breakdown in communication between upstream and distro package maintainers. It may also be that authors don't have time to talk with ~3 (Debian, Fedora, ???) distros, each with different packaging processes and rules.
drewcrawford 12y ago
Distro packages don't solve the needs of software developers. They solve the need of distros, which are different (and conflicting) with the needs of software developers. Therefore you will always have an eternal struggle between language-level package managers who work for developers and system ones that work for distros. If there was some simple way to lob a tarball over the wall and get package inclusion on Debian, Fedora, Gentoo, etc., then that would be one thing. In reality however the number of random GitHub repos >> the number of package maintainers. I know that Debian uses a variety of technical and social methods to discourage new packages, and most people's software just isn't popular enough to overcome those barriers, even if some of the reason they're not popular is because they're not well-packaged (sort of a catch-22 there). Not to mention people who install via apt or rpm are perpetually out of date. Now compare that with pip or rubygems--one package to maintain, installs more-or-less everywhere, accepts packages regardless of popularity, end users are more often up-to-date. Better for software developers' problems in every single dimension. Sure that's bad for Fedora maintainers, but what are Fedora maintainers doing for me?
- Hello71 12y ago
  > Sure that's bad for Fedora maintainers, but what are Fedora maintainers doing for me? ensuring a myriad of things that individual developers simply don't seem to care about, ranging from simple testing to inter-package compatibility to licensing to init scripts to old package cleanup to unbundling to...
StefanKarpinski 12y ago
Your view assumes that all language-level packages are already so mature that each of Debian, Gentoo, Arch, brew, MacPorts, etc. have a person whose responsibility it is to make a system-level package for that language-level package. What about new packages? If language packages are to be distributed on each system using the system package manager, then the way to get a new package into the hands of programmers is to a) write the package and b) before anyone has used it, spend a couple of years convincing a person on each system to create and maintain a system package for this new and completely unused Ruby/Python/Perl package. I guess that's reasonable if you're dead set on only using software that was written ten years ago.

by Hello71 12y ago

voltagex_ 12y ago

Ir seems like there is often a breakdown in communication between upstream and distro package maintainers. It may also be that authors don't have time to talk with ~3 (Debian, Fedora, ???) distros, each with different packaging processes and rules.

drewcrawford 12y ago

Distro packages don't solve the needs of software developers. They solve the need of distros, which are different (and conflicting) with the needs of software developers. Therefore you will always have an eternal struggle between language-level package managers who work for developers and system ones that work for distros. If there was some simple way to lob a tarball over the wall and get package inclusion on Debian, Fedora, Gentoo, etc., then that would be one thing. In reality however the number of random GitHub repos >> the number of package maintainers. I know that Debian uses a variety of technical and social methods to discourage new packages, and most people's software just isn't popular enough to overcome those barriers, even if some of the reason they're not popular is because they're not well-packaged (sort of a catch-22 there). Not to mention people who install via apt or rpm are perpetually out of date. Now compare that with pip or rubygems--one package to maintain, installs more-or-less everywhere, accepts packages regardless of popularity, end users are more often up-to-date. Better for software developers' problems in every single dimension. Sure that's bad for Fedora maintainers, but what are Fedora maintainers doing for me?

Hello71 12y ago
> Sure that's bad for Fedora maintainers, but what are Fedora maintainers doing for me? ensuring a myriad of things that individual developers simply don't seem to care about, ranging from simple testing to inter-package compatibility to licensing to init scripts to old package cleanup to unbundling to...

StefanKarpinski 12y ago

Your view assumes that all language-level packages are already so mature that each of Debian, Gentoo, Arch, brew, MacPorts, etc. have a person whose responsibility it is to make a system-level package for that language-level package. What about new packages? If language packages are to be distributed on each system using the system package manager, then the way to get a new package into the hands of programmers is to a) write the package and b) before anyone has used it, spend a couple of years convincing a person on each system to create and maintain a system package for this new and completely unused Ruby/Python/Perl package. I guess that's reasonable if you're dead set on only using software that was written ten years ago.