octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Philip Nienhuis
Subject: Re: Fwd: [Pkg-octave-devel] Popcon stats for the DOG packages
Date: Thu, 22 Mar 2012 18:10:02 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100701 SeaMonkey/2.0.6

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.

I simply repeat my answer in other words:
If some package "X" that depends on the io pkg requires io's Java-based functions to work, "X" had better depend on the Java package as well. Given the current setup of the io pkg and the octave-forge package system, there's no other way. I'm afraid similar reasoning goes for other packages, too. I don't perceive this as necessarily evil; it's just one consequence of the flexibility we have in octave-forge.

I confirm this. To put it another way, all packaging systems that I am
aware of (Debian's APT, Cygwin, Redhat's RPM…) treat the dependency
relationship as a transitive property: "A depends on B" and "B depends
on C" implies "A depends on C".

See my answer to Carnë above.
Please note that I don't disagree at all with either of you on the principle, but the actual circumstances in octave-forge render such a "transitive" dependency system unreliable.

BTW it's not quite the first sound principle I see breaking up on the real world's non-compliance :-)

Philip


reply via email to

[Prev in Thread] Current Thread [Next in Thread]