Carnë Draug <carandraug+dev@gmail.com> writes: > On 22 March 2012 11:58, Philip Nienhuis <pr.nienhuis@hccnet.nl> wrote: >> Carnė Draug wrote: >>> On 21 March 2012 19:36, Philip Nienhuis<pr.nienhuis@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@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
Attachment:
pgp2QVeDExPGT.pgp
Description: PGP signature