El Thu, Jun 30, 2005 at 05:16:36PM +0200, Andreas Tille va escriure:
> On Thu, 30 Jun 2005, Sergio Talens-Oliag wrote:
> > The good long term solution is to use the ``Source:`` field for the CDD
> > name.
> Well currently the source of Debian-Med packages is "debian-med". The
> CDD name in the package building process would be only "med" because
> the packages should be named only "med-<task>". I would have no trouble
> to rename the source to just "med" if you think that it is a good
> solution to name the source like the CDD prefix of the meta packages.
> I just want to mention that this would not work with current Debian-Med
> and Debian-Junior, but we have to change a certain amount anyway ...
Well, another solution is to check if CDD is set to something in the
environment and use that as the CDD name and if it is not set use the Source
name.
> > For the current scripts it's enought to replace the CDD asignment with:
> >
> > CDD=`sed -n -e "s/^Source: \(.*\)$/\1/p" $CONTROL`
> Sure, that's easy, but I wonder if we should immediately the cdbs helpers
> in a common place.
I don't plan to keep those scripts around for long, but maybe it makes sense
to put them on the cddtk package.
I've grouped them into one script that is installed into
'/usr/lib/cddtk/debscripts/cdbs-helper' and I've created a simple makefile
to be included into the debian/rules file; right now my cdd package only
needs the following line into debian/rules:
#include /usr/share/cdbs/1/rules/cddtk-meta.mk
> > As I said, all that is done on those scripts would be included on the
> > cddtool, but I don't know if I'll use the current model or a different
> > one,
> > we can talk about it.
> Well, but we need something to play with. ;-)
> Look, I gave you my nice toy (cdd package) in Florence 9 month ago?
> I would love to start playing again. ;-)
> So why not trying how this works in the current state. I've got some
> ideas what to do but I'm bound to wait ...
Well, you don't need to wait to test things, I have not done as much as I
wanted to do, but if you tell me what you need from the current code I can
try to avoid breackage (if you update the package you will notice that I
have changed the cddtool commands, grouping the functional subcommands into
only one, as I had a lot of replicated code on the previous implementation).
> > The main problem is that I don't want to build the metapackages with the
> > main CDD package; the idea is use them to resolve dependencies (something
> > that can be done without actually installing them) and to install
> > configuration files (those can be distributed with the cdd package and
> > moved to the right places if a task is enabled, keeping all the CDD data
> > only in one package).
> Ups - I'm afraid I do not understand your plan.
My idea is to avoid distribution of metapackages into the debian pool, as
that has caused problems for unstable -> testing migration scripts in the
past.
The fact is that the metapackages don't need to be installed at all, we only
need to verify that their dependencies are satisfied when installing or
upgrading a CDD and that information would be distributed with the CDD
description package.
To verify the metapackage dependencies I've been thinking about different
approaches:
1. Generate and install the metapackages on the user machine.
2. Generate a fake Packages file, do a fake apt-install of the metapackages
to get the packages that have to be installed, upgraded or removed and
install them without the metapackages.
3. Modify apt-get to support a satisfy-depends, removing the need to do a
fake apt-get install call.
> (BTW, you did not answered my question whether I will meet you at
> DebConf5.)
Oh, sorry, I missed the question.
Anyway, I won't be in Debconf this year, maybe I'll go to Debconf6, but this
summer I thought that it was better to stay at home my 7 months old son.
> > Anyway I'm still thinking about how I plan to do things and I've already
> > uploaded a simple script to build empty packages to the ``cddtk/scripts``
> > subdir that can be used to build metapackages on the local machine using
> > only a binary package control file as input.
> I just checked the new stuff out and will give it a try ...
Check it again, I've done a lot of small changes and the command unification
thing.
> > Sure, feel free to implement the support as you see more appropiate. My
> > idea
> > is that the menu thing is on the configuration space of the CDD, so
> > probably
> > the right thing to do would be to distribute the menu information for each
> > task with the description and provide a script on the lliurex-runtime
> > system
> > to enable those menus when a task is enabled.
> Yes, sure. But I wrote some code to build the user menus from the menu
> entries of the dependencies sorted into a hierarchy of our tasks. This
> makes things much easier, because in the most simple case you do not
> have to provide anything - it is just there but you need some code
> which is called in the postinst to sort this out. This code is contained
> in the cdd-common package. Moreover this package contains the code to
> maintain system users in CDD groups. Just have a look into this package.
> IMHO we can take it as it is for the moment.
I have not looked at it, but if it can be used as is I have no problem
on including it on the cddtk package... tomorrow I'll take a look at it.
Greetings,
Sergio.
--
Sergio Talens-Oliag <sto@debian.org> <http://people.debian.org/~sto/>
Key fingerprint = 29DF 544F 1BD9 548C 8F15 86EF 6770 052B B8C1 FA69
Attachment:
signature.asc
Description: Digital signature