[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: about commit r562

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"?  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.


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!

Kind regards

       Andreas.

--
http://fam-tille.de
Reply to: