Hi pacman&arch devs Pacman like many other linux package managers are created with c projects in mind. Those projects usually release sources as tarball. It is expected that user will install dependencies and compile sources. Pacman takes those responsibilities and handles it very well. The situation a little bit different with packages for language ecosystems that have their own language-specific package manager (let me call it domain-specific package managers). Those package managers also aim to install system libraries/binaries (very similar to what pacman does). Let me give you a few examples of such package managers: perl - cpan js/nodejs - npm ruby - rubygems haskell - cabal ..... I played/changed a bunch of Arch packages recently and every time I modified/updated a package for perl-* or nodejs-* I felt like I am wasting my time. Think about it. Those CPAN/rubygems/... packages already have all required information: author name, license, latest released version, dependencies, postinstall instructions, instruction how to run tests,.... It means if one adds a perl-* package he has to copy/paste a bunch of info from CPAN package info. Could this situation be improved? Could Arch generate packages automatically or semiautomatically from domain-specific package? Something like *_PACKAGE macro for PKGBUILD: $ cat PKGBUILD # maintainer -- foo@bar.com CPAN_PACKAGE('net-ssl') then when maintainer runs "makepkg --regenerate" (or something like this) the tool will: - download CPAN index - check if index has newer package than we have locally - extract all package information from CPAN package - add/update that info below CPAN_PACKAGE macro The reasons why automatic generation/update is better than manually tracking packages: - less chance for errors, e.g. tool will never forget to add a correct dependency and tests - saves maintainer time. It is better if maintainers work on a real bugs rather that waste time on updating package fields. - more consistent packages. They will use the same compilation/installation flags. - easier to make large changes, e.g. haskell packages need "!strip" option - now we can change macro itself instead of manually changing PKGBUILD files one by one. What do you think? There are a few questions that should be resolved: - There should be a way to customize generated packages. e.g. some domain packages require 'native' packages as a dependency. - Some packages can be distributed as a domain package and as a source tarball. It might cause a confusion. An example - many javascript packages were tarballs, but recently a lot of them moved to npm (node-js package manager). We probably want to stick with domain package. - Naming convention. Generated domain packages should be named as 'PREFIX-DOMAINPKGNAME' e.g. perl-net-ssl. Non-domain package cannot use that prefix. In fact Arch can go even further. For example import *all* domain packages and automatically create PKGBUILD files for them. Would it be cool to disable CPAN/rubygems/... and install everything via pacman? In fact having the same software installed via different package managers (e.g. pacman & CPAN) can cause a confusion like this [1]. [1] https://mailman.archlinux.org/pipermail/arch-general/2013-May/033599.html