bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] A call for justification of feature / library / extension


From: David B. Lamkins
Subject: Re: [Bug-apl] A call for justification of feature / library / extension proposals (was Re: Tk/Tcl interface)
Date: Thu, 24 Apr 2014 22:38:45 -0700

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]