"Lennart Sorensen" <lsore...@csclub.uwaterloo.ca> writes: > Absolutely. As a user I have a nice package management system that I > know how to use and which works well. I don't need another one.
> It is not the job of a language developer to invent yet another bloody > package distribution and installation system. Just because windows > doesn't have a decent way to handle software installations doesn't mean > other systems don't know how to do it well. My upstream experience is that people generally use the package management properties of things like CPAN in two main cases: when using operating systems with deficient package management or scope of packages, or when using old systems that can't be updated for some reason. CPAN is hugely popular with Solaris admins, for example, because good luck finding real Solaris packages of most of the things you care about. Red Hat is similar; a lot of common Perl modules are packaged, but far fewer than are packaged for Debian, and it's common to need something that isn't part of the base Red Hat distribution. The problem with the general feeling that they're inferior versions of real package management is that the above use cases mean that the packaging components of something like CPAN aren't ever going to go away, since upstream will continue to support users on those platforms, or users who are on lenny and refuse to upgrade for some reason. And since those components exist and people get used to using them to get their jobs done on Red Hat, they'll naturally use them on Debian as well without being aware there are better alternatives. Or when they're on squeeze and want to do some sort of cutting-edge development. Thankfully, at least with Perl, they co-exist fairly well, although people get bitten by having outdated versions of things installed in /usr/local from an old CPAN run that should have been, but weren't, supplanted by better versions available through the package manager. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877gmuxlfy....@windlord.stanford.edu