Re: debian-edu build process, once more
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
Reply to: