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

[Philip Nienhuis]

Carnë Draug wrote:
> On 22 March 2012 17:10, Philip Nienhuis<address@hidden>  wrote:
> > Sébastien Villemot wrote:
> > > Carnë Draug<address@hidden>    writes:
> > >
> > > > On 22 March 2012 11:58, Philip Nienhuis<address@hidden>    wrote:
> > > > > Carnė Draug wrote:
> > > > > > On 21 March 2012 19:36, Philip Nienhuis<address@hidden>
> > > > > >   wrote:
> > > > > > > - (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).
> > > >
> > > >
> > > > I don't think this is true or that it should even work that way. I'm
> > > > not a seasoned programmer but I haven't seen a system of dependencies
> > > > working that way. Debian's apt system, perl's and python modules also
> > > > don't work that way. The developer of package A that depends on B
> > > > should not need to worry about how B works or what B needs and listing
> > > > all the dependencies of B as dependencies of A is doubled work. A only
> > > > needs B to work and doesn't need to know how. It might even be that in
> > > > the future, B changes and is no longer dependent of C. The user would
> > > > still end up installing C even though it's not needed.
> >
> > Encapsulation and abstraction.
> > Sure, in an ideal world it would work. But clearly not always in
> > octave-forge, where functionality of individual packages can cover many
> > different but overlapping subjects and users are free, and should be free,
> > to install any package for just some tiny part of that package's total
> > functionality.
>
> They are free to do that, that's why there's "pkg install -nodeps",
> for those who understand what they are doing and are willing to take
> risks.

IMO for the io pkg, "nodeps" would only confuse users, especially 
Windows users, which probably constitute the largest io pkg userbase as 
well.
(You don't hear me say that average Windows users don't "... understand 
what they are doing ..." <g>)

> But anyway, if it is possible to have complete functionality of io
> package without any other package installed like you say it is then
> it's ok. This is not creating a problem so it's not like there's
> anything to fix.

No, I (think I) didn't write/say that. Just to clarify:

The OF io-package contains:
1.- some functions that don't need any dependencies
2.- many functions that are dependent on the Windows AND/OR the Java 
package.

Category 2 functions simply auto-select any available supporting 
dependency package.

For XLS files there's a preference for the Windows package as that 
offers the most complete support.
As to ODS: with the Windows pkg ODS support is/can be at least on par 
with that of the Java pkg. At work I see no real difference between ODS 
files created/read by Excel 2003 + plugins, and LibreOffice, and that 
propagates to the io package.

Using the Java pkg as dependency very probably works on all platforms, 
but with limitations.

So there you are - to repeat what I wrote earlier:
> ......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.

In an other post today I already mentioned that I see reasons for making 
package dependencies platform-dependent - at least for the io pkg. As 
long as that isn't implemented I'd rather keep the dependencies "suggested".
But yes I realize that the io package is a bit of an extreme case :-)

Philip