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

[Philip Nienhuis]

Sébastien Villemot wrote:
> Carnë Draug<carandraug+dev at gmail.com>  writes:
>
>> On 22 March 2012 11:58, Philip Nienhuis<pr.nienhuis at hccnet.nl>  wrote:
>>> Carnė Draug wrote:
>>>> On 21 March 2012 19:36, Philip Nienhuis<pr.nienhuis at hccnet.nl>    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