10 bellhop is a generic packaging server.
13 - Every tool and platform eventually has it's own packaging tool (python eggs, ruby gems, perl modules, javascript packages)
14 - You should be able to build a project even when the external intrnet is unavailable (local mirroring)
15 - You should be able to save versions of the packages used by a project even when the external sites / mirrors have dropped them (pinning)
16 - Serving new type of package shouldn't involve setting up an entirely new ecosystem to basically serve files over http
19 - Provide a single package providing source called ''bellhop' (since he'll carry your packages for you)
20 - bellhop will use a plugin architecture to provide interfaces for various packaging interfaces
21 - user will be able to use whatever the default packaging client tool is (yum / apt / pip / easy_install / gem / npm / whatever)
22 - bellhop will provide a common backend in a consistent format for storing the packages, regardless of how the client expects the files to be served)
23 - bellhop will provide a plugin architecture for the backend storage of packages
25 - The default will be filesystem bases, with packages being stored under /var/www/bellhop/{package_type}/{package_name}/{available_versions_of_package_name}
27 - bellhop will be written in a language that'll be easy to get accepted in distros default packaging schemso
28 - Target fedora and debian packages for starts
29 - limit dependencies / use established/proven libraries
30 - default python 2 version for now ?
34 - pypi : python : nothing special ? : /var/www/bellhop/pypi/_packagename_/_package_versions_ : URL format
35 - cpan : perl : Downloads some index files first : /var/www/bellhop/cpan/_packagename_ / _package_version_ : URL format
38 - Just set up the repos with httpd / nginx url rewrites ?
42 - see pinto's concepts of stacks and pins: http://perlmaven.com/pinto-tutorial