3 ms·

That's not what distribution packages are for. The point of distribution packages is to run other packages in the distribution written in that language. You're

by dkarl 15y ago

That's not what distribution packages are for. The point of distribution packages is to run other packages in the distribution written in that language. You're drawing a distinction between "apps" for users and "packages" that users don't directly use, and you're drawing it in a place that is not traditional for Linux. When someone installs Amarok (or finds it pre-installed by their distro) they expect to find a music player they can use, not something that only supports the music player needs of the distribution. In Linux, Perl isn't any different from Amarok. It's an "app" that many users understand and use directly. The packages you get when you install Perl using yum or apt-get are very much intended for users, unless Linux distributions want to depart from history and start treating programmers as second-class users compared to the "normal" users who would use a music player but would never use a programming language. If vendors need their own ancient Perl distro to support their toolchain, that's their problem, and they should figure out how to accomplish that and still give users a usable, up-to-date Perl.

jrockway 15y ago
What you say is true in theory. In the real world, the included versions of Perl and Python are for the OS and packages the OS installs. As soon as you install modules in the system directory or upgrade/downgrade /usr/bin/(perl|python), you run the risk of your system breaking. Perhaps this is not ideal, but it's a fact. Amarok can do whatever you want it to, because plugins install in your home directory. Never in the course of using Amarok do you affect the system's view of what Amarok is. This is now how people treat the system Perl install; they "sudo cpan -i ..." and end up upgrading modules that the rest of the system depends on. Most of the time, this works fine, because most authors are very careful to maintain backcompat. But sometimes, it doesn't work that way, and now your system is broken. Using your own Perl gives your application 100% control over its environment, and that's how you eliminate the unproductive task of fixing your servers (and workstations) all the time.

by dkarl 15y ago

jrockway 15y ago

What you say is true in theory. In the real world, the included versions of Perl and Python are for the OS and packages the OS installs. As soon as you install modules in the system directory or upgrade/downgrade /usr/bin/(perl|python), you run the risk of your system breaking. Perhaps this is not ideal, but it's a fact. Amarok can do whatever you want it to, because plugins install in your home directory. Never in the course of using Amarok do you affect the system's view of what Amarok is. This is now how people treat the system Perl install; they "sudo cpan -i ..." and end up upgrading modules that the rest of the system depends on. Most of the time, this works fine, because most authors are very careful to maintain backcompat. But sometimes, it doesn't work that way, and now your system is broken. Using your own Perl gives your application 100% control over its environment, and that's how you eliminate the unproductive task of fixing your servers (and workstations) all the time.