Alberto Simões <al...@alfarrabio.di.uminho.pt> writes: > That is the problem. There are too many options out there. Can we > control all Linux distributions packaging systems?
All? Maybe not. Many? Yes. All of the more popular? Certainly. Installing (updating, removing) modules is currently dealt with by the package managers of Debian, Ubuntu. Suse, Fedora, RHEL, and all other deb/rpm based distro's. It's rather pointless to try to do it differently (you think we can do it better? Srsly?) on those platforms. > And Windows, or even Mac OS X? For those there is no real option... Modules belong to a Perl install. Windows and Mac (I'm not sure about the latter) do not have standard Perl installs. Windows has some semi-standard Perl kits: ActiveState Perl, Citrus Perl, Strawberry Perl. The ActiveState PPM handles (un)install of modules quite nicely. ActiveState Perl and Citrus Perl are available for Mac as well. BTW: For desktop users I advocate providing packaged applications (self-contained kits that include Perl and modules) instead of dealing with separate Perl kits and loose modules. > Finally, we are here for ages, and ee can't even have the more > relevant Perl modules correctly installed on major distributions (my > honest opinion). Exactly, and that is because we keep putting energy in ExtUtils::MakeMaker, Module::Build, Module::Install, CPANPLUS, Dist::Zilla and so on, instead of trying to integrate with package management of the systems that have it. There comes a time that Perl applications will be available for Android and iOS. These applications will be installed via the corresponding app stores. Other desktop systems will follow suit. The question of 'updating and removing modules' will be void. In a few days Perl will be 25 years old. It's about time Perl, and the Perl community, grow up and stop trying to solve yestercentury's problems. -- Johan
