[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Octave 3.6.1 mingw for windows - updated
From: |
Philip Nienhuis |
Subject: |
Re: Octave 3.6.1 mingw for windows - updated |
Date: |
Fri, 06 Apr 2012 00:47:56 +0200 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100701 SeaMonkey/2.0.6 |
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
- Re: Octave 3.6.1 mingw for windows - updated, (continued)
- Re: Octave 3.6.1 mingw for windows - updated, Carnë Draug, 2012/04/05
- Re: Octave 3.6.1 mingw for windows - updated, Przemek Klosowski, 2012/04/05
- Re: Octave 3.6.1 mingw for windows - updated, Lukas Reichlin, 2012/04/05
- Re: Octave 3.6.1 mingw for windows - updated, Jordi Gutiérrez Hermoso, 2012/04/05
- Re: Octave 3.6.1 mingw for windows - updated, marco atzeri, 2012/04/05
- Re: Octave 3.6.1 mingw for windows - updated, PhilipNienhuis, 2012/04/05
- Re: Octave 3.6.1 mingw for windows - updated, Lukas Reichlin, 2012/04/05
- Re: Octave 3.6.1 mingw for windows - updated, John Frain, 2012/04/05
- Re: Octave 3.6.1 mingw for windows - updated, PhilipNienhuis, 2012/04/05
- Re: Octave 3.6.1 mingw for windows - updated, Jordi Gutiérrez Hermoso, 2012/04/05
- Re: Octave 3.6.1 mingw for windows - updated,
Philip Nienhuis <=
- Re: Octave 3.6.1 mingw for windows - updated, Carnë Draug, 2012/04/05