octave-maintainers
[Top][All Lists]
Advanced

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

Re: packaging system


From: Quentin Spencer
Subject: Re: packaging system
Date: Wed, 15 Jun 2005 14:18:39 -0500
User-agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513)

Stefan van der Walt wrote:

>On Wed, Jun 15, 2005 at 02:08:06PM -0400, John W. Eaton wrote:
>  
>
>>On a related topic, it would be useful to have a packaging system for
>>contributed Octave code.  That would allow people to independently
>>distribute collections of functions.  Octave forge would still be
>>useful as a place for collaborative deveoplment, but we would not be
>>restricted to a monolithic Octave plus a monolithic Octave forge
>>collection.  Given a functioning package system, there are a number of
>>things that could be removed from Octave and placed in independent
>>packages.
>>    
>>
>
>I suggest that we take a look at the Debian package format, and create
>a similarly structured archive.  This archive will, for example,
>contain the following:
>
>pre-install.m
>post-install.m
>pre-remove.m
>post-install.m
>content.tar
>INDEX
>
>Then, some choice functions could be provided to aid the pre- and
>post-install/remove scripts.  The INDEX format used in Octave Forge
>works quite well -- and we already have a parser for it, written in
>C++.
>  
>
Let me just point out one thing before we get too far into this
discussion. Past discussion of a possible packaging system has alluded
to TeX, R, and perl as examples. I'm not familiar with R, but both of
the other two do not require compilation for their packages. A packaging
approach will work for m files, but octave-forge has a fair amount of
.oct files, some because they are wrappers for other things, and some
because "it's faster that way". I really don't see this packaging
approach being particularly practical for compiled code--the sheer
number of possible OSs and architectures (especially with the increasing
popularity of x86_64-specific Linux distributions) becomes quickly
unmanageable.

-Quentin



reply via email to

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