On Thu, Oct 22, 2009 at 01:08:24PM +0200, Andreas Tille wrote: > On Thu, Oct 22, 2009 at 12:22:53PM +0200, Holger Levsen wrote: > I would prefer autogeneration. Everything else is a hack. Browsing changes > in SVN might answer the question who injected this and can explain the > reasons. According to changelog it was Vagrant for the education-thin-client > package (which is the only questionable hardcoded package.
...snip... > Package: education-thin-client > ==> If there is no strong reason to use Depends here than this should > definitely turned to a task tasks/thin-client. > Explanation: I took over the strategy to turn Depends in the tasks > files to Recommends in the resulting debian/control file. This turned > out to be practical and there was no real need to change the code > invented by Petter years ago. 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. 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. > In the long run I would like to see an option for forcing real > Depends also in metapackages. So when I realise my plan to base > building of metapackages based on UDD information I will probably > do a s/Depends/Recommends/ in all tasks files to express what we > really mean. This will leave a Depends as a "real" Depends ending > up in the control file. IMHO this is more clear. if the autogeneration is desireable, then this approach will work better, yes. but it will also have to account for architecture-specific dependencies, like usplash and whatnot. live well, vagrant -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
