Re: Octave 3.6.1 mingw for windows - updated

[Philip Nienhuis]

Jordi Gutiérrez Hermoso wrote:
> On 5 April 2012 16:47, PhilipNienhuis<address@hidden>  wrote:
> > Jordi Gutiérrez Hermoso-2 wrote
>
> > > If Windows had a nicer packaging infrastructure, it would be nice
> > > if you could say "pkg install package" and the package would
> > > install forever. Sadly, it doesn't, and "pkg install" is
> > > essentially useless in Windows,
> >
> > I'm a bit confused. From where did you get this idea?
> >
> > "pkg install package" perfectly works in Windows,
>
> How perfectly does it work for tracking dependencies? For example,
> will it download and install GiNaC if you use the symbolic package?
> Will it almost never result in users complaining about not being able
> to compile packages?
>
> If it doesn't do this, I consider it essentially useless.

Interesting point of view.

What you actually imply is that Octave's pkg command itself is useless 
and should be ditched in favor of *nix distros pkg management systems.
To which I can agree to *some* extent.

But as a workaround, OF packages could at least issue informative 
diagnostic messages pointing out to users how they could solve missing 
dependencies etc themselves.
E.g., the Java pkg could first check for Java JDK presence and if not 
found, abort with a message explaining what steps a user should take to 
fix problems ("install a Java JDK" and "show me where the JDK is"), 
rather than complain in an obscure place that "Java: no" (where it 
actually means "no Java JDK found in the place you told me to look for it").
Currently it silently installs only half way in that case. (BTW earlier 
on I suggested that pkg.m lacks a rollback mechanism for failed 
installations like this.)

There are probably more packages that behave similarly.

In the io package (that I maintain) I included some troubleshooting & 
setup scripts exactly for that reason: help users fix often-encountered 
problems by themselves.
A system package mgmt system may be superior and "convenient", but there 
are more ways to help users sort it out while not requiring to fully 
dive into "intricacies".

> > > I think in this case, trying to make things too convenient for
> > > users doesn't expose them to the intricacies of the underlying
> > > problems,
>
> > I'd rather think that convenience should NOT be avoided, not even
> > for the sake of "exposing them to intricacies .... etc". We should
> > rather focus on solving those intricacies.
>
> Those intricacies are too difficult to solve. They require a close
> collaboration between Octave and Octave-Forge, a fully functional
> packaging system for Windows, and tireless packagers working on
> Windows.
>
> If we can't solve them, it's worse to try to hide them and pretend
> that everything is working fine. It's not. Octave and Octave-Forge is
> made by many individuals, who are at odds at each other, and can't
> agree on what certain functions should do. Packaging for Windows is
> very hard because Windows is a hostile environment for free
> development.

(not wanting to advocate Windows here, just some explanation:)

That's nonsense, sorry.
Just look at SourceForge - that contains thousands and thousands of free 
and good programs that run OOTB on Windows.

Sure, programs like Octave that heavily rely on FHS conventions etc, 
have problems on systems that have other design philosophies (yes, 
Windows does have them. But they are alien to *nix ports). I wouldn't 
call that "hostile" bur rather "unfortunate", I don't think it's on purpose.

Lack of a system wide package mgmt system isn't so hostile either. Over
the years I tried a few Windows programs that will download and install 
dependencies if needed (even politely asking for permission to do so). 
AFAICS it isn't even very hard to set up yourself. It's just that you 
have to do it on a per-program basis, which can become messy but OTOH is 
much less complicated and vulnerable than e.g. the system-wide rpm database.
Moreover, since Windows XP a lot of the notorious "dll hell" issues 
(which in fact are contradictory dependencies) have been solved within 
the system itself (the SXS stuff), so one might even argue that a 
critical part of a package management system has become built-in.

> We don't have enough people working on solving these
> problems, despite your efforts and mine.

Solving - no.
Mitigating - we can at least give that a try.

Philip