El Mon, Sep 27, 2004 at 09:54:40AM +0200, Andreas Tille va escriure:
> >Of course, coming from the Debian community, the CDD community began with
> >the answer ("yes") and then went about trying to create and argue a
> >justification. We've even defined the technology based on what would or
> >would not allow us to honestly call ourselves "Debian" and have attempted
> >to grasp onto definitions of "Debian" that make that possible. Debian-NP
> >and every CDD is still trying to figure out what it means to be Debian and
> >Debian-NP at the same time -- how does one strike that balance?
>
> IMHO we would have less problems if we would try to relay on a common tool
> set which technically glues together what is separate in terms of the target
> user group. I'm absolutely convinced that relaying in common tolls will
> show whether it is possible to go together or if everybody tries to go their
> own way. My main concern about all CDD stuff I did (docs and cdd package)
> was to get people involved and just to *use* these tools. I'm absolutely
> convinced that there are many things to enhance and the current state has
> drawbacks.
I totally agree that working with current tools and try to enhace them is
the way to go and as soon as I've worked with them (really soon now :-) I'll
try to give as much feedback as possible.
> Before I went to Florence I asked here whether somebody is using the cdd-dev
> package. I try to give a summary of the answer which is more or less
> symptomatic.
> Later I give some technical comments to these answers.
>
> 1) I use a slightly hacked version.
>
> 2) We also tried debtags and we planned to build the metapackages from the
> debtags database.
>
> 3) I didn't use cdd-dev but thers ways to do the same.
>
> 4) Joey Hess recently modified the debian-edu meta package build system
> and tasksel to support custom tasks
>
> You obviousely see that there are at least four drawbacks of the current
> cdd-dev package (or at least there are people who refuse to use it because
> they see drawbacks for their special work). But I never have seen a
> complain on this list or a bug report or whatever. So we are in danger to
> drift away even in such simple matters like building tiny little packages.
Well, I don't have drawbacks about the current cdd-dev package (I still have
to use it to have any), what I don't like is the use of metapackages per-se,
the inclusion of empty packages on the pool just for selecting packages do
not really seem the right thing to do and the problems debian-edu
metapackages have caused blocking migrations from unstable to testing don't
seem reasonable either.
> My point in building the cdd-dev package was: Save time in building my own
> packages. It worked so far because I've got great help by Cosimo and I've
> got a great enhancement. I guess other people working in CDD have more time
> than me or just a different philosophy about time saving tasks: Why not just
> solving the constraints of cdd tools instead of using at least four
> different approaches.
As I said, I haven't spent time reinventing anything, I only looked
different aproaches before starting to build our CDD (well, we have been
doing the things a CDD will concentrate on when all the tools are in place,
like selecting packages and preparing and testing configurations).
> When I builded the cdd package I kept two things in mind: Try to (re)produce
> the (at that time) existing meta packages (which were Jr, Med and Edu) while
> using the most advanced way (which was at this time Debian-Edu). Otavio did
> a great job in organizing the CDD SVN archive at alioth and I hoped that
> people whould switch to this common SVN using the common tools while they
> will be enhanced to their needs. But currently we are drifting away again.
> So at least I would love to discuss the reasons for why we tend to drift
> away, whether this can be fixed or whether there are technical reasons to
> differ even in the least common multiple to build tiny little packages with
> depencies. Is there a reason to avoid the CDD svn or are there just time
> constraints (well, I can't no really see in how far giving a differnt URL
> for the SVN is time consuming, but anyway ...)
I promise I'll use current infraestructure, it's only that unfortunately I
have no code to upload right now (and maybe I'll start with the CDD doc,
anyway), but as soon as I have something I will do it right away.
> Regarding to the comment of the answers above:
I hope to see other answers, from my part:
> ad 2) Sergio, We also had no real time to discuss this in detail, but I
> know that Free thinks similar. I try to move this to the docs. But
> *currently* there is nothing (no code) available and *if* you write some
> code, please do it in the CDD svn and not somewhere else. The idea is good
> but hidden in some peoples mind and this sucks. Just keep the code open (I
> mean also *visible* for all CDD folks).
Well, as I said before, I don't like the idea of using metapackages, but as
I plan to use them initially I just looked as how we were documenting our
*package selection*; what we started to do is writting a table for each
proposed metapackage and the list of packages it had to include (the
handmade configuration packages are also included on those lists, but the
config. package declares its dependencies if it needs something to work,
like python, for example).
After looking at debtags I found that a better way of declaring our meta
packages is to tag the included packages with a category equivalent to the
cdd and meta package, i.e., for a package included in an hypotetical
lliurex-server meta package we could use this in a /etc/debtags/tagpatch.d
file:
samba: +lliurex::server
I have no code to move that to a metapackage, but it's really easy to do it;
just getting the output of a command like:
$ debtags grep "lliurex::server"
will give you the list of packages using this tag from which is easy to
generate a dependency list for a metapackage.
I'll try to work on it next week (this week we are installing pilots and I'm
almost sure I will not have time for it) and add an option to generate
metapackages in this way using existing cdd-dev code in the subversion
repository.
--
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