El Mon, Jul 04, 2005 at 09:55:09AM +0200, Andreas Tille va escriure:
> 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.
No, the idea is to export the environment variable from the rules file:
#!/usr/bin/make -f
export CDD=med
include /usr/share/cdbs/1/rules/cddtk-meta.mk
That should work.
> > 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.
Well, the idea is that before and after each apt-get call we can verify the
CDD consistency, and we don't need the metapackage installed for that.
>
> > 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)!
Before removals the apt hooks are also called.
> > 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.
No, it doesn't need dpkg-dev, with the mkedeb script that is included on the
scripts subdir of the package you only need the binary packages control
files (that can be distributed with the CDD description package)
> > 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.
Yes, maybe it's better to install the metapackages to keep the dpkg database
informed of which packages have to be installed, with the empty metapacakges
is quite cheap.
> > 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.
Yes, it is useful for testing in any case, if I have the time I'll try to
implement it, but I have tons of things to do before... ;)
>
> > 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. ;-)
No, I also prefer low temperatures, but there are also some logistics on
that issue, like keeping free days for August, when his mother will be
working... ;)
> > 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)
Hmmm. I can arrive form work, so probably you are right and it is your
firewall... anyway if you have time to look at the code I usually upload the
latest versions of the cddtk to:
http://people.debian.org/~sto/cddtk/
The only change on the lliurex-cdd package is the removal of the
build-tools, a build dependency on cddtk (>= 0.0.10) and a new rules that
only contains the new include:
#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/cddtk-meta.mk
> > 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.
If I have time I'll look at it today.
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