El Tue, Feb 28, 2006 at 02:22:14PM +0100, Andreas Tille va escriure: > On Tue, 28 Feb 2006, Sergio Talens-Oliag wrote: > > >First, for the ones that don't read planet.debian.org, > > Which is me. Any links (or private mail) what happened to you? That is the initial post: http://mixinet.net/stoblog/2006/02/03#20060203-tired_and_burn_out And that is the public announce on my blog (I announced it internally the 13th of February, luckily it was quite fast, I found a new job on 10 days): http://mixinet.net/stoblog/2006/02/24#20060224-three_days_left_at_lliurex > >Unfortunately I've had to go > > "Had to go" does not sound funny. Well, it was a nice work and IMHO a good project, but there is a lot to improve on the management side. I had to go because I was considered a problem by one of the teachers of the team (I believe that HE is the problem, but that is a personal view) and the situation arrived to a point that I was really unhappy going to work and I decided that I don't need to spend my time fighting with people I don't respect, there are better and more constructive things to do. Luckly I talked with some old friends and I got a good job offer, so I decided to move to a new place ASAP and I start on the new place next Monday... ;). > >Now, I would like to know if there is still interest on the toolkit and ask > >to those interested what should I do now. > > I personally have very big interest, because I stalled cdd-dev work to > wait for a working CDDT (and personal real live reasons but this is not > the main point). > > >My idea was to split the current system into different source packages and > >upload the things that already work before than the things that still need > >work. > > Sounds reasonable. I'm starting to do that right now, moving my target to sid/etch on the move (i.e. the documentation failed to build on sid because changes on python-docutils, so I changed the Makefile to work using the sid package). > >Basically that will mean to upload the current cddt-runtime first, as it is > >already usable to customize installed systems building configuration > >packages > >(in fact it is probably usable by debian-edu and other people using > >post-installation scripts). > > Sounds promissing. I don't know how many people is aware of what is available on that package, but I explain it here to know how many of you are interested. Currently this package implements support to handle customizations that support package upgrades; the package includes a set of shell functions that can be by configuration packages to install hooks that modify configuration files before and after package installation (pre and post dpkg hooks) and/or when configuring network interfaces (pre-up, post-up, pre-down and post-down /etc/network/if.*.d scripts). The main problem with this customization handling system is that the apt hooks are not a good solution in the general case, the fist problem appears when there are errors on an installation or update, if the user calls apt through apt-get, aptitude or synaptic and the call succeds everything works as expected (that is, all the pre-dpkg and post-dpkg scripts that have to be called are called), but if something fails (i.e. a postinst script) the post-dpkg scripts are not called, possibly leaving updated programs with the non customized configuration until an apt run succeeds. The second and most obvious problem is that the system is not used if someone calls `dpkg` directly; for that case I've included a `cddt-dpkg` script that parses the arguments as if it were `dpkg`, runs pre-dpkg scripts if needed, calls `dpkg` and runs post-dpkg scripts after the run. I believe that using this script instead of the real `dpkg` for CDD is a good idea, once it is tested and we are sure that it does not break anything. In fact if this script replaces the real `dpkg` and apt is configured to use it the current cddt-apt hooks could be removed enterely. Another good option would be to ask the dpkg development team to consider the option of adding support for pre and post hooks to dpkg, which is, IMHO, the right place to put this support, as dpkg knows when it is going to install a package and when the package has been installed and configured succesfully. Besides the hook scripts, the package also includes a tool called `cddt-divert` that can be used to divert files on a fashion similar to `dpkg-divert`; it basically replaces a system file with the contents of a user provided one, keeping copies of the original and replacement files and optionally recording who has *diverted* the file. The usage of this tool is optional, as the configuration hooks don't care about how or what you change, but it has worked quite well for me until now and seems reasonable to use a system that this one that can be used to revert changed files easily. The function library also includes shell functions to process template files that include variables of the form _@_VARIABLE_@_, a simple mechanism I've used for some customizations (on that cases the configuration files are generated from templates instead of modifying the debian package files), but nothing prevents a CDD from using other tools to modify configuration files; for example I've used `gpp` to process templates and if the idea is to customize configurations modifying existing files tools like `sed` for simple changes or `cfengine` for more complex ones can be very good options. > >The second package will be the cddt-tools package, but it will have less > >functionality that the one initially described, that is, I would add the > >missing things to make it a good way of building metapackages from the > >current > >CDD description files, leaving the implementation of the mainteinance > >commands > >and the support of other package selection mechanisms like debtags for a > >version 2 package. > > While Debian-Jr decided to set the focus on DebTags I think having > something that supports metapackages is still important. IMHO > DebTags might have great advantages over metapackages I think we > should do this *in adition* and not as a replacement. Thus having > stable methods to build metapackages is important, IMHO. I agree and I believe debtags can and should be supported, but it will need more work and time, that's why I believe that it can be done later. > >And the last one will be the cddt-installer package, split into the needed > >udebs (probably one will be enough) and the cddt-tools components related > >to > >the installer (tools needed to get preseedings from the CDD description > >and to > >be able to select CDD tasks to install). > > All three things have more or less separable functionalities and thus > it might make sense to split them up into different binary packages > (generated from a common source once they are ready). Well, in fact after looking at it, the installer .udeb package has to be quite simple; once the support to generate CDD udebs is available the installer component can be implemented and included on the standard debian-installer pool. If done right it will only be included on a debian-installer image if the user adds a CDD udeb on the d-i build system as a local package. The other components belong to belong to the original cddt-tool program, as it is the tool that parses the description files... I supose I can start by finishing the metapackages thing on the cddt-tools package, upload that and later add installer related functionalities one by one. > >I don't know how much time I'll use to work on the CDDT in the near future, > >but I'm sure that having someone else interested will help to keep the > >project > >going and probably it can develop faster that before, as things have not > >been > >as fast as I wanted them to be while being paid to work on the development > >of > >a Debian Derived Distribution. > > Hoping you get paid by someone else in the first place and continuing > to work in the second place for sure. Oh, don't worry about that, as I've said at the beginig of the mail, I left only after having a new job, I have a family and I would not have leaved voluntarily without a new place to go. In fact nobody told me to go, I did it because I felt it was the best thing for me and I have the feeling that on the short term it is bad for the project, but they will do, nobody is marked as essential: yes on projects like that. 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