Re: debian-edu build process, once more
On Thu, Oct 22, 2009 at 12:22:53PM +0200, Holger Levsen wrote:
> Arg. Thanks for making me see.
You are welcome. ;-)
> And much less I understand why there are three binary packages, who come
> directly (and exclusively??) from control.stub, while the rest is
> autogenerated?
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.
Package: education-tasks
--> This is some specific package which more or less contains a tasksel
helper. It makes no sense to put it in tasks.
Package: education-menus
--> This is also a specific package which makes no sense as task. My
lonterm goal is to find a more clever soltion in the blends-dev
framework which generalises the *-menu package generation. But
this is not (yet) high on my todo list. So we have to and probably
can perfectly do with this hack introduced by José.
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.
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.
> Doing so now. But do we actually need control.stub except for the source
> package bits?
There is no real need to keep debian/control.stub in the source tarball.
But I have never seen a need to remove it. So if you are concerned about
this template we might leave only the generated debian/control.
> > As I said previosely: It is not a good idea to keep debian/control in
> > SVN.
>
> We don't do that.
A file debian/control is kept in SVN (currently *depending* from usplash)
at least in my checkout.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: