Re: pkg install and distribution problems

[Sergei Steshenko]

----- Original Message -----
> From: Jordi Gutiérrez Hermoso <address@hidden>
> To: Olaf Till <address@hidden>
> Cc: Octave Forge List <address@hidden>; John W. Eaton <address@hidden>; 
> Octave-help <address@hidden>
> Sent: Monday, May 28, 2012 7:29 PM
> Subject: pkg install and distribution problems
> 
> 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.

This is a grossly wrong conclusion.

If one runs a system like Gentoo, he/she builds from source _everything_.

A bug/screwup on the way, and the _whole_ system can become unusable.

I build more than 300 targets from source, and I do not screw up my system. Not 
because I do not make mistakes, but because I do not install into system 
locations. So, my mistakes are mistakes at user level.

I even build not under my regular user ID - a small security precaution.

Compartmentalization is a good proactive practice.

> 
> 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.

'pkg.m' is simply _buggy_. I managed to hack it to the extent I can do both 
local and global install and locally installed packages shadow the globally 
installed one as they should.

Ordinary users rarely understand 'pkg.m' first and foremost because output to 
stdout and stderr is screwed up by 'pkg.m' developers - stderr is seen 
immediately, stdout is seen after 'configure' or 'make' fails.

> 
> 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.

No, there are all kinds of C/C++ libraries that have Per bindings, I build them 
too, and I know Perl packaging essentially works. I needed to very little 
"massaging".

I remind that 'cpan' (Perl module installation program) is available under free 
SW license, so Octave developers have a good place to "steal" the code and 
ideas from.

> 
>>  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.
> 

No, you need a release. As in every other SW project.

>>  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.

No, 'mkoctfile' and appropriate 'configure' scripts should take care of this. 
If they don't, it's the developers fault.

> 
> 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.
> 

No, build mechanism should just work. In full compliance with GPL spirit.

> 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.
> 

'pkg.m' is a problem because it is shamelessly buggy.

> I think the solution is to bring OF closer to Octave and other related
> things. Discussion towards this solution is underway.
> 

Yes, there should be responsibility and accountability. Preferably in one place 
rather than in two (Octave + forge).

> - Jordi G. H.


--Sergei.