Hi, On Freitag, 30. Oktober 2009, Vagrant Cascadian wrote: > we definitely should *not* make a tasksel task out of it. I was only thinking of creating the debian/control fields for that package by the means of the tasks dir and blends-dev magic. I'm not aware that this automatically creates a tasksel task too. > i definitely recall it not working as a recommends, but can't recall > exactly what the issue was at the moment. this could have changed in the meantime... > if recommends aren't met, we need > to make sure that nothing assumes those packages are installed, such as > debian-edu-config hooks and such. in those cases we should use depends. (and fix blends to support it.) > if people want to switch it back to recommends, go ahead. i don't have the > time to test it. you've been warned. :) ok, I'm not in favor of doing this, as I'm in favor of releasing rather sooner then later :-) > the whole method of abusing recommends to avoid installability problems > leaves me with an unsettled feeling. why? as said: stuff which needs depends, should declare depends. (this is what we do in the tasks/* files, just that blends doenst make depends out of it. but it shall.) > apparently, it was even a release goal > for lenny to not have unsatisfyable recommends in main > http://release.debian.org/lenny/goals.txt: cool. still, unsatisfiable depends cause it to block testing migration, while unsatisfiable recommends dont have such an effect. but of course this goal is still worthwhile and we should use arch-specific recommends where applicable. regards, Holger
Attachment:
signature.asc
Description: This is a digitally signed message part.