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

[Carnë Draug]

On 22 March 2012 17:10, Philip Nienhuis <pr.nienhuis at hccnet.nl> wrote:
> 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.

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.

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.

Carnë