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

Re: about commit r562

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.

José L.

> Kind regards
>         Andreas.

Attachment: signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente

Reply to: