Re: Examples for CDDtool
On Sun, 3 Jul 2005, Sergio Talens-Oliag wrote:
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.
I think this is no option for auto-builders. It also happened in the past
that people tried to build packages for Architecture=all.
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
This fits exactly my wish. ;)
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).
I'll check out this evening new cddtk and lliurex example.
The fact is that the metapackages don't need to be installed at all, we only
Hmmm, in the past I had the argument that the existence of a meta package might
prevent a local administrator to remove any dependant packages by chance. It
might be often the case that the administrator is no specialized user and
does not really know what his user might need. I observed this by myself that
I sometimes wanted to clear my system from some things I thought I would not
really need but apt-get told me that it is about to remove junior-<something>.
Thus I became aware that my son would become angry on me if I would proceed. ;-)
So having the meta package on the box sounds at least a reasonable thing.
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.
... but before removing anything (see above)!
To verify the metapackage dependencies I've been thinking about different
approaches:
1. Generate and install the metapackages on the user machine.
... because you would finally know which distribution the user uses (including
extra sources.list entries)? Sounds reasonable. It would require dpkg-dev at
least but this would come at low cost because it could even deinstalled afterwards.
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.
Well this sounds basically time consuming to me for the very view win to not
install the meta package. I'm even not yet convinced that ist is a good idea
to not install the meta package.
3. Modify apt-get to support a satisfy-depends, removing the need to do a
fake apt-get install call.
Well, this sounds reasonable in any case.
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.
Ahhh, yes, this is a reasonable argument. I just used this last year for my
son even if he is 14 years older, but we made a vacation trip to Italy at this
time. On the other hand I would prefer staying in the not so hot climate of
Helsinki with a baby than in Spain currently. But it might be that it's only
me who is more comfortable at lower temperatures. ;-)
Check it again, I've done a lot of small changes and the command unification
thing.
Can do it this evening. Stupid firewall here:
$ LANG= svn co https://mixinet.net/svn/cddtk/trunk cddtk
svn: PROPFIND request failed on '/svn/cddtk/trunk'
svn: PROPFIND of '/svn/cddtk/trunk': could not connect to server (https://mixinet.net)
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.
As I said: It just contains some scripts which are called by the postinst
of meta packages. Be aware that some of them are quite hackish.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: