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

[Carnë Draug]

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.

On 22 March 2012 12:09, Sébastien Villemot <sebastien.villemot at ens.fr> wrote:
> The point is that Debian has more types of relationships that the octave
> pkg system. So I had to make a decision on how to translate the
> "Suggests" of the octave pkg system into the Debian system.

To make things clear then, the octave pkg system does not have a
"Suggest" type of relationship, there is only "Depends". However, pkg
allows the DESCRIPTION to have as many optional undocumented lines as
the package manager wants and "Suggest" was thought appropriate for
this situation. But octave's pkg ignores this completely.

Carnë