[Pkg-octave-devel] Fwd: Popcon stats for the DOG packages

[Philip Nienhuis]

Hi Carnë:

Carnë Draug wrote:
> On 21 March 2012 19:36, Philip Nienhuis<pr.nienhuis at hccnet.nl>  wrote:
>> Carnë Draug wrote:
>>> On 11 March 2012 17:00, Philip Nienhuis<pr.nienhuis at hccnet.nl>    wrote:
>>>>
>>>> Sébastien Villemot wrote:
>>>>>
>>>>>                                          the dependency is not enforced
>>>>> on Debian. We should probably change that in the future.
>>>>
>>>>
>>>> I'd conclude that situation can only mean that I underestimated the need
>>>> out
>>>> there for JSON/PCH/fexist functionality....
>>>
>>> Another conclusion, much more negative, is that there's many users who
>>> installed the io package and, unable to use it, gave up
>>
>> Maybe. But if the xlsopen/odsopen scripts cannot find supporting system SW
>> (ActiveX or Java) they clearly say so. That should ring a bell.
>>
>> But perhaps I could add better messages (there's still time before
>> io-1.0.18):
>
> That would be nice. I actually added a call to lasterr on try/catch
> block because I kept having problems and couldn't figure out why. Once
> I could see the actual error message it was obvious the problem was a
> misconfigured java package.

Yes that is a notorious trap, there are many reports in [OctDev] ML 
about the Java package appearing to be installed fine but in reality 
being miscompiled or even just partly installed (i.e., only the scripts).
pkg.m itself doesn't yield any warning in the latter case.
(BTW I perceive this as something that can (and should) be fixed in the 
Java pkg itself.)

IMO any package should be able to check its own (basic) operation, 
perhaps by a test script called from postinstall.m or pkg.m. But that 
isn't quite as straightforward as it looks at first sight.
For Java pkg it is still easy: just a try/catch around a "javamem.m" 
invocation conveniently summarizes & checks essential pkg operation. For 
io it already gets messy, perhaps the spreadsheet test scripts I've 
committed lately can be a start. But how to automatically test graphics 
stuff, or interactive functions?

>> - (Windows only) if no ActiveX/COM found: "Apparently no MS-Excel installed,
>> trying to fall back to Java"
>>
>> - If no Java is found: "No Java JRE or JDK detected - essential for
>> spreadsheet support"
>
> Does this even make sense? Imagine another package that has the io
> package as dependency. Allowing the package to exist as installed and
> "half functional" may compromise the other package.

Of course it makes sense; but that other package must also made be 
dependent on -in this case- Java and/or Windows, then. Because only then 
io would have the required functionality for the other pkg.

This is sometimes overlooked by pkg maintainers: during installation pkg 
A says "pkg B is needed", OK, you then try to install B only to learn 
from B that pkg C is also needed. Etcetera.
Package maintainers should not only assign direct dependencies, but also 
implied ones. So if package A depends on B which depends on C, A also 
needs to explicitly depend on C; depending on what functionality is 
actually needed of course (no pun intended).

As regards the io pkg, there are several good reasons to keep Windows 
and Java as "suggested" rather than strict dependencies.
First, there are a few functions which don't need Java or Windows pkgs; 
and in upcoming 1.0.18 there'll be compiled functions again (csv/xml) 
that have no dependencies either. I can imagine that some users only 
need those and don't care about the spreadsheet I/O stuff.
Secondly, even if you want spreadsheet I/O, on *nix there's no use for a 
Windows pkg and on Windows many users have Excel installed so don't need 
the Java pkg.
For Debian, Sébastien decided otherwise and made io dependent on 
octave-java - very good, that's the OSS principle at work.

>>                                                         (of octave or
>>>
>>> spreadsheet --- hopefully the later) instead of fixing it by
>>> installing the java package.
>>
>> Perhaps it would help if the dependencies could be made platform-specific:
>>
>> - Windows pkg OR Java pkg on Windows
>> - Java pkg on all other platforms
>
> On this case there's no actual need to check the platform, simply java
> || windows would suffice since if it's not a windows system, it won't
> have the windows package installed.
>
>> but currently that is not supported by Octave (-Forge).
>
> That would require to patch pkg (which is already being done though
> not to implment this).

Yes I know about the attempts to simplify pkg.m. A welcome initiative.

Yet pkg.m has more issues:

(1) Shadowing of core functions is only catched after pkg installation. 
I've worked on this, I've even got some half-baked results invoking 
contributions in this ML, but I got lost in a fatal combination of lack 
of time, personal medical issues and pkg.m's complexity :-)
I haven't forgotten this, but it's not at the top of my priority list.


(2) pkg.m isn't able to roll back failed package upgrades. Imagine these 
scenarios:
1.- User has a functional pkg, perhaps prepacked from some Linux distro 
or MinGW bundle
2.- User needs a new feature => a newer version of the pkg, which 
otherwise works fine
3.- User tries to upgrade the package, but that fails
4.- User now has no more functional pkg at all. Plus: depending pkgs now 
are broken as well.
   Or:
A.- User upgrades a package, it works fine, but now some dependent 
packages don't work anymore with that new release.

In some cases re-installing from the distro's package manager may help, 
in other cases the user may simply get lost.

A while ago I looked into this as well. The principle is easy: just 
backup any old oct & script dirs of the pkg + octave_packages before 
installation proper, and if installation fails, delete the new dirs and 
restore the backup.

Unfortunately I got lost somewhere in pkg.m - as written earlier here, 
pkg.m is (was) just too complicated.
An underlying killer issue was that successful termination of pkg.m (= 
w/o conspicuous errors) doesn't guarantee at all that the actual package 
installation was successful.
As a solution for the latter I thought of a dedicated pkg backup 
directory where updated or uninstalled packages are moved to, and from 
where such earlier pkg versions can be restored using a "pkg restore" 
command. Once the user has sufficient faith in a new pkg release, the 
backup dir might get cleaned up by a "pkg cleanup" command. Perhaps some 
reminders during startup of Octave ("You have old package backups, see 
'pkg cleanup'.") may trigger such user actions. Again, easy at first 
sight, but of course I hit other gotchas (I forgot, it's quite a while ago).
Again, I might pick up again but this is not at the top of my priority 
list either.

As a contributor / package maintainer I'm not quite sure if all this 
functionality is worth the trouble.
As a user I'd love to have it, though - I clearly see the big advantage: 
one can always return to a known good restore point with minimum fuss.


Philip