Hi Vagrant, On Freitag, 23. Oktober 2009, Vagrant Cascadian wrote: > i set it up as hard depends to remove a list of hard-coded packages to > install from the debian-edu specific ltsp-build-client plugins, which would > fail if the appropriate packages weren't available. so having them as > depends in the education-thin-client package ensures that those packages > end up on the CD, simplifies the ltsp-build-client plugins greatly, and > allows for more proper tracking of the dependencies we actually rely on. Isn't that the same with recommends? I dont see what a depends gains us here. > if the packages actually work without a given hard depedency, we could add > an architecture-specific dependency or move it to a recommends, if > appropriate. it has to properly handle if the packages aren't actually > installed before moving it to recommends or removing the dependency on > certain architectures. recommends are installed by default (and we dont change that default), so I still fail to understand why recommends are not enough. and recommends have the advantage that its no problem if they dont exist for a certain architecture. can you explain, please? regards, Holger
Attachment:
signature.asc
Description: This is a digitally signed message part.