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

Sébastien Villemot sebastien.villemot at ens.fr
Thu Mar 22 15:48:24 UTC 2012


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.

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".

> 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.

Thanks for the clarification.

-- 
Sébastien Villemot
Researcher in Economics & Debian Maintainer
http://www.dynare.org/sebastien
Phone: +33-1-40-77-84-04 - GPG Key: 4096R/381A7594
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-octave-devel/attachments/20120322/f8b7844f/attachment.pgp>


More information about the Pkg-octave-devel mailing list