Re: [OctDev] pkg install and distribution problems

[Alexander Hansen]

On 5/28/12 9:29 AM, Jordi Gutiérrez Hermoso wrote:
> On 28 May 2012 12:01, Olaf Till <address@hidden> wrote:
>> On Thu, May 24, 2012 at 11:11:36AM -0400, Jordi Gutiérrez Hermoso wrote:
> 
>>> You should not be using pkg install to install OF packages in
>>> Debian. They are already packaged for Debian with apt. So e.g.
>>> instead of doing "pkg install signal" from Octave, you should do
>>> "aptitude install octave-signal" from bash.
>>>
>>> In fact, I wish we could stop telling people to use pkg install,
>>> because it's a very brittle way of getting packages to people.
>>
>> advocating the use of packaged (Debian) Octave Forge packages is one
>> thing, but explicitely discouraging 'pkg install' is another. In
>> some cases the latter could actually mean 'please stick with a buggy
>> package or a package lacking important features'.
> 
> It depends if those bugs are important or not for the person using the
> package. Typically, for a Debian user, they are not. If Debian users
> wanted to be running the latest of everything and compiling everything
> from source, they wouldn't be using Debian, but a source-based
> distribution like Gentoo.
> 
> And yes, bugs you know are better than new bugs you don't. Development
> and distribution needs to take pauses to document and fix bugs. I
> don't think always being on the cutting edge and compiling from source
> is for everyone. I think it's for very few people. In other cases,
> stick to the packaged versions. Only do source compilation if you know
> that the packaged version won't work for you.
> 
> pkg install is brittle. It requires having a system setup in a very
> specific way. It does not work for most people. When it fails, it
> produces error messages ordinary users rarely understand. We should be
> recommending it as a last resort and as seldom as possible. It's
> really a developer tool.
> 
> I know it gets compared to package manager for other languages like
> Perl and Python, but in those it's a bit easier since they usually
> only distribute Perl or Python code respectively. Here we almost
> always have to deal with C++ code which can't be distributed as
> quickly as purely scripting code, because compiling things correctly
> is far more difficult than and intricate than only using interpreted
> languages.
> 
>> Octave Forge packages are generally in a quite flowing state, there
>> is no 'stable branch'
> 
> This is a distribution problem. We need to fix OF, and if a *release*
> is made, it should be a reasonably stable release.
> 
> Otherwise, we should get rid of releases and just tell everyone to use
> the latest svn tip for everything. I think this is a little worse than
> the current things we're doing.
> 
>> and I doubt that Debians scheme to stick with some stable version is
>> thouroughly applicable here,
> 
> It's applicable everywhere. All software has the same distribution
> problems that Octave has. We're not special.
> 
>> And I don't think using the 'pkg install' way is that difficult.
> 
> Then you will have to explain to ordinary users how to compile and all
> the ways in which compiling can fail and where things will be
> installed after it's compiled and why it's broken. It may not be
> difficult for you, but it's difficult for everyone else.
> 
> Many Octave users are Matlab refugees. Matlab doesn't make them
> compile to obtain packages, so they're a little confused when Octave
> does.
> 
>> While pre-packaging may help many people, persons with serious
>> interest in some packages functionality should not be discouraged to
>> use the native Octave way.
> 
> They should be discouraged unless they like compiling and can figure
> out compiler errors when they happen. They should be discouraged if
> they don't already know that they need the latest version for whatever
> reason.
> 
> Packaged versions are fine for most people. Not for you or I, but for
> almost everyone else, packaged versions are fine.
> 
>> Please don't take this as an insult or as disrespect of Debians
>> packaging work. But I'm a bit disquiet since I think things are
>> going to far here.
> 
> OF has a distribution problem. pkg install is not the solution, or at
> least not the whole solution.
> 
> I think the solution is to bring OF closer to Octave and other related
> things. Discussion towards this solution is underway.
> 
> - Jordi G. H.
> 

Here's my take on the situation, as the person responsible for most
things Octave on Fink:

We're a source-based distribution, but we lean more toward the Debian
approach than that of Gentoo, preferring to build from well-defined
upstream releases.  It's possible to work from the tip of a VCS for us,
but that takes additional effort.  I've been working under the
assumption that the Octave Forge release versions are the most
appropriate versions of the packages to distribute to general users,
since to my mind "release" equates to "stable enough for everyday use".
 That, and because I don't want to have to wade through a bunch of
commit messages to assess where a particular svn revision may have
broken.  I have to spend enough time worrying about that on my _own_
project. :-)

Where installing packages via a  distribution wins out over just running
"pkg install" manually is in the handling of dependencies.  Octave, like
any packaging system, doesn't have a mechanism to enforce installation
of packages that it doesn't control.  For Octave Forge packages that
only depend on other Octave Forge packages, then things are nicely
self-contained.  For packages that need external libraries, on the other
hand, it's easy to wind up in the situation that Jordi described, with
an error message that's nontrivial to diagnose.  And using the svn tip
doesn't normally help with _this_ issue.

If there were a "virtual package" tool that Octave forge packages could
run in their build process to verify that all of the dependencies were
installed and/or to provide human-readable output if they aren't, that
would make "pkg install" more useful as a standalone option.
-- 
Alexander Hansen, Ph.D.
Fink User Liaison
http://finkakh.wordpress.com/