El jue, 21-02-2008 a las 15:20 +0100, Andreas Tille escribió: > On Thu, 21 Feb 2008, José L. Redrejo Rodríguez wrote: > > > For those who doesn't know it, I've working on Debian Edu and one of my > > interest is the reorganization of the menus on any freedesktop.org > > compatible destkop. With this purpose, I was creating an education-menus > > package. > > Great. > > > In Debian Edu, when calling cdd-gen-control, the flag "-D" is used to > > change all the dependencies to recommends in the tasks. That option > > leaves only education-tasks as the only package that could have > > dependencies, as for the rest they were switched. The education-menus > > package needs to depend on desktop-profiles, so current behaviour didn't > > work for me. > > After commit r561, control.stub will admit more complete binary packages > > entries in control.stub. It's a simple fix and seems to work perfectly > > (as long as these packages have the same prefix as the <cdd>-tasks > > package or the <cdd> is the first binary in control.stub). > > As I wrote in private mail I agree perfectly with this patch. > It does not look like breaking anything I'm aware of and if > this simple change solves your problem it is fine. > > > The main purpose of this email is reporting about the rationale of that > > svn commit. But now, I have another question. All the packages in the > > tasks directory will depend on <cdd>-tasks. But, what maybe some CDD > > will need to depend on all the binary packages available in > > control.stub. > > I'm afraid I do not fully understand your example? Do you mean that > a CDD might want not to turn the "Depends" statements in the tasks > files into "Recommends"? Nope, I meant the opposite. I'll try to explain it better with my education-menus example: after r562 there can be an education-tasks and an education-menus at control.stub, with their dependencies. After executing cdd-gen-control, the generated debian/control file will keep the education-menus & education-tasks entries and will add an education-xxx package for every file at tasks/ . These education-xxx packages will depend on education-tasks, and will recommend (when using -D flag) the listed packages in their own task files. My idea is that a cdd might need these education-xxxx packages depending on education-tasks & education-menus. I.e.: depending on all the binaries packages listed in control.stub in spite of using -D to switch all other dependencies into recommendations on the metapackages. That does not apply to my education-menus package, it's just an example, but the idea came to my mind when I thought that might be a possibility with some other features that don't fit in -common or -config packages. Hope it's clearer now. > If this is your concern I would like to > explain that tasks file syntax was invented before Recommends became > installed by default via apt (and friends). So from the point of > user comfort we are fine with Recommends. From the point of flexibility > to leave something out despite our recommendation we are better than > to go with Depends. So I think all existing CDDs agree with this move. > IN case a future CDD really wants to contrast with this common > agreement we have to find a way to tweak the cdd-dev tools to > comply to this non-default requirement. As long as this requirement > does not exist I see no need for a change. > > > That's not my case with education-menus but maybe some of you have some > > thoughts on it. > > I for myself do not try to find solutions for future problems that > are not likely to happen. :-) > So if I did not missunderstood your point I would keep things as > they are. > I fully agree, just wondered if knowing the idea someone could think of needing it ;-) > > P.S. I haven't modified debian/changelog for the cdd sources yet. I'll > > do it if nobody argues against the commit, then I'll ask for the upload > > of the new version to the Debian archive. > > Just for the record as I write in private mail: You are welcome to > add yourself to Uploaders and feel free to modify debian/changelog with > your signature. It was always intended to have more than one effective > uploader of the package. Perhaps we should even put this mailing list > as the maintainer of the package instead of myself. Please don't be > shy! Ok, I'll do it. Thanks for your support. Cheers José L. > > Kind regards > > Andreas. >
Attachment:
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente