On Fri, 2014-04-25 at 12:54 +0800, Elias Mårtenson wrote: > To shift this discussion from namespace to (what I previously > mentioned being more important) that of library packaging: > > > I don't think using Linux packaging is the best idea. I run Ubuntu and > OSX at home, and Arch Linux and Red Hat at the office. That's four > different packaging systems right there. >
I, too, view this as a problem. Creating a model in which package maintainers do the work for each distro as they do in Linux presupposes that there are enough interested parties on each platform to find someone who's willing to do the extra work of understanding the tools and conventions. > > Rather, I'd like to see something like Quicklisp for Common Lisp, Gem > for Ruby or Pip for Python. All we have to do is to define a simple > description format, and a central repository. I think I could > implement such a thing pretty quickly as a proof of concept if this is > something that would be acceptable. You and I are on the same page, for certain. I mentioned earlier that I had some thoughts about packaging. The only thing I'd add to what you've said so far is that the package format should admit incremental additions to the metadata. That way someone who picked up a package already tailored to one or more platforms might add the metadata necessary to make the package also work on a previously unsupported platform. Think of this as a package-centric approach as opposed to the distribution-centric approach used by Linux. For example, let's imagine we've already packaged apl-sqlite and apl-cf for Fedora and Solaris. There'd be metadata in each package to deal with platform-specific compilation steps and installation paths. Someone who wanted to port those packages to, say, OS X would need only to *add* metadata to make it work on that platform. This way each package would grow organically to support multiple platforms and variations.
