Re: postinst scripts failing because a new conffile wasn'taccepted: Is it a bug?
> My proposal to avoid such problem is to implement multilevel > configuration, where the package default configuration and the local > overrides are stored in separate files, making sure local > configuration do not affect changes to the package default, and thus > no question is asked during upgrade. I have a tool that: - is able to read the local configuration file - fill any blank with default values provided by the packages - re-write local file with user's values and enw default values. The only hitch is that reading and writing file may be tricky since the syntax of configuration files varies widly from one package to another. Would this kind of tool interest you ? Cheers -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 3
Adrian von Bidder <[EMAIL PROTECTED]> writes: > From a graph algorithm point of view, if I'm not very mistaken, > dependencies being guaranteed to be a directed graph instead of a > generic graph should allow some simplifications/efficiency > improvements in apt and other tools, too. For the record, dependencies are a directed graph by nature. Preventing circular dependencies will get you a directed acyclic graph (DAG) which is, IMHO, easier to handle. HTH -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Box does not switch of on halt
Andreas Tille <[EMAIL PROTECTED]> writes: > since about three weeks I observe problems when issuing halt > on three different testing-boxes (two older desktops without ACPI > and one laptop with ACPI). The computer just does not switch off. > If I try to reboot it is also impossible, because the shutdown > process stops at the same point where halt stops. The last > messages on the console are: > > Shutdown: hda > System halted. I've sometimes noticed a similar behavior when I try to switch my computer off with KDM's shutdown procedure. Using "halt" always works fine. I humbly admit that I did not provide much information, I just hope to give you some more hint about this problem... HTH -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 5
Joey Hess <[EMAIL PROTECTED]> writes: > Steve Greenland wrote: >> Sure, it allows some one to install foo-data without the program that >> uses it? So what? It's unlikely to happen by accident, and annoying to >> those doing it intentionally. (Just like those foo-docs that depend on >> foo, although they are mostly fixed, now.) > > I don't buy the often-made argument that foo-data packages are > generally useful to install just to look at the beautiful data. As a casual user, if I want the "foo" functionality, I'll probably want to install foo and not even look at foo-data. Another point of view of this problem can be expressed this way: - foo without foo-data is *broken* hence the need for a dependency. - foo-data without foo is not broken (because there's not program to invoke), but is *useless*. May be a better solution would be to flag foo-data as "useless alone". (I would love to be able to hide from aptitude all these "useless alone" packages so I could sift faster in the package list). HTH -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Is adding dh_config and a postinst snippet ok ?
Hello I'd like to add the following files in libconfig-model-perl: - /usr/bin/dh_config - /usr/share/debhelper/autoscripts/postinst-config-model In short, the goal is to use these files to perform smooth upgrade of configuration data during package upgrades. See [1] for full details. But we're not there yet. Before deciding whether dh_config is a good idea or not, I want to check that these files will not break anything just because they are installed on your file system. So, what so do you think ? Will users run into problems when these files are installed ? Can dh_config be called by dh without warnings ? (Note that this should be harmless if no option or specific files are provided to dh-config. dh_config will just exit(0) ) All the best [1] http://wiki.debian.org/PackageConfigUpgrade -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Is adding dh_config and a postinst snippet ok ?
Joey Hess writes: > Installing third party debhelper commands won't break anything in > debhelper, but nor will dh automatically call random such commands. See > the sequence addon information in debhelper's PROGRAMMING file for > information about adding third-party commands to dh command sequences > (enabled via the --with switch). ok, understood. > "dh_config" is a rather generic name for a third-party debhelper command > to use. I'd generally rather reserve such names for use by debhelper, > and have third-party command names be a bit more clearly bound to the > package that contains them. Agreed. So, what name should I use for this dh snippet that will add instructions to perform system configuration upgrade during package upgrade ? How about dh_config_model_upgrade ? This would leave room for other dh_* to provide alternate methods for package config upgrade... I would also need to deliver a matching /usr/share/perl5/Debian/Debhelper/Sequence/config_model_upgrade.pm Is this fine or too verbose ? All the best -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Is adding dh_config and a postinst snippet ok ?
Hello Jonathan Yu writes: > I see these two tools as complementary, rather than competing, > technologies. You can use the data parsed via Augeas (which to me > seems like more of a lexer/tokenizer part, kind of like what yacc/lex > do) to get data from the file using a grammar. Indeed. From a user's point of view, the big advantages of Augeas are: - provides a unified API to edit files in /etc (whatever their syntax) - preserve structure and comments of original files - available in several languages (Ruby, Perl, Python, C ...) The main drawbacks: - Only augtool user interface - Not much validation. - Error messages can be cryptic. > Then you need some code, which is provided easily through > Config::Model, to actually validate what you've got, make sure it all > makes sense (for example if you're trying to parse XHTML, then to make > sure certain elements like are inside ). Compared to Augeas, Config::Model provides: - stronger validation that can take into account more than one parameter (1) - integrated help - filter parameter according to user skills - configuration upgrade capability (2) - more user interfaces (Perl/Tk, Curses ...) - understandable user message On the drawback side: - Only Perl API - Comments and structure of original file is lost The latter point can be avoided if Config::Model::Backend::Augeas is used. You can then get the best of both world. But this has a cost: you need to have both Augeas lens and Config::Model model. See libconfig-model-openshh for example. > I suppose you could also write such code yourself, but then you'd need > to write both accessors and mutators to do that sort of validation, > which I imagine is something Config::Model does on your behalf. Yes. > Finally, it should be noted that Dominique is the maintainer of both > modules, so he wouldn't have packaged them both (and went through all > the trouble of writing Config::Model in the first place) if there > wasn't a good reason :-) Using Augeas will avoid writing writer and parser for some configuration files. Only the models will be left to write. > But I'll leave it to him to correct my understanding here. You're doing fine. Thanks :-) All the best (1) For instance, in xorg.conf it could validate that a Monitor mode is choosen from the list of default Modes or from the list of Modes declated in the same file. (2) Models can contain rules to be able to migrate deprecated configuration paremeters to newer parameters. For instance, old sshd_config parameter 'KeepAlive' could be migrated to new 'TCPKeepAlive' during package upgrade. -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Is adding dh_config and a postinst snippet ok ?
Raphael Hertzog writes: > A question about this project, I've recently discovered augeas, how do you > compare yourself with it? I forgot to mention that a video of the Config::Model presentation done during French Perl Workshop is available there: http://fpw2009.ubicast.eu/videos/free/64/ Unfortunately, this video is available only in French. All the best -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Please test krb5-config in experimental
Sam Hartman writes: > Last night I uploaded a more or less rewrite of krb5-config to > experimental. The goal of this rewrite is to significantly reduce the > number of cases where users are asked questions or where the resulting > configuration is completely wrong. For what it's worth (knowing that this message may come too late), Peter Knowles has done some work to create a Kerberos model for Config::Model. This model (and Config::Model) could help: - in providing validation for Kerberos config files - upgrading configuration during package upgrade (see current thread on dh_config_model_upgrade) As a bonus, you would also get a GUI to edit Kerberos config files. (a wizard for Config::Model is also planned so users can start a config from scratch) That said, I do not know how complere is Kerberos model, or if Peter still has time to work on it. Peter, what's the status on Kerberos model ? All the best -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [config-model-users] Please test krb5-config in experimental
> The model was pretty much 100% complete and had been well tested on my > box. However, I ran out of free time to work on this, so I never got > around to implementing the suggestions that you made back in September > 2008. Peter, do you have any hope to resume working on it ? Or should I look for a volunteer to take it over ? All the best -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RFC: Proposal to improve package configuration upgrades
Hello The other day, I was upgrading cups and dpkg did ask me the usual way if I wanted to keep my cups config file or take the upstream version. Like always, I asked for a diff and was quite puzzled because I did not remember anything about editing this file. Then I remembered that I did a modification through cups admin web interface. Previous common story you might say. But for a casual user (like my mother-in-law which now use Debian Lenny ;-) ), this can be frustrating: - I did modify the config through a nice web interface - during the upgrade, I either have to look at all the gory details of cupsd config file or I have to loose my configuration. I was thinking that this is a typical case where package upgrade could be better handled with Config::Model help. So, I've written a wiki page [1] that explains: - how configuration upgrade are managed by Config::Model - how to implement such upgrades with Approx example: * create a configuration model for approx.conf * the patch required for approx package scripts - how to use a new dh_ tool that will simplify setup of configuration upgrade for package based on debhelper (dh_config_model_upgrade). A patch for openssh-server is provided. - the bonus (config GUI) - the current limitations (*) To approx and openssh maintainers: Is there something missing that would prevent you to use Config::Model for your package ? Other package maintainers: what do you think ? Can this be applied to the configuration of your packages ? You can either reply to this mail or directly edit the wiki page [1]. All the best [1] http://wiki.debian.org/PackageConfigUpgrade (*) Manoj, I have not attempted a model for sendmail... ;-) -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: Proposal to improve package configuration upgrades
Guy Hulbert writes: > On Thu, 2009-17-09 at 14:11 +0200, Dominique Dumont wrote: >> The other day, I was upgrading cups and dpkg did ask me the usual way >> if I wanted to keep my cups config file or take the upstream version. > > This email looks very familiar. Did you send something quite similar a > few months ago? Yes, one very first stab in debian-devel aroundin February . I was encouraged by Zach to write some code. I felt that the code alone would not be enough so I created the wiki page. I sent a first request for comment of the first draft of the wiki page in April to debian-perl. Thanks to the comment from Jonas Smedegaard, this led to some clarification of the specification of a configuration model and the creation of dh_config_model_upgrade. Then GSoC happened. Being GSoC mentor did slow down work on Config::Model and package config upgrade. ;-) > I see the wiki page started on: 2009-03-23 > > but there is no discussion page yet ... perhaps we should use it ? That's a good idea ! All the best -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#548193: ITP: [PACKAGE] -- graphical configuration editor for approx.conf
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: libconfig-model-approx-perl Version: 1.001 Upstream Author: Domminique Dumont URL: http://search.cpan.org/dist/Config-Model-Approx/ License: LGPL Description: graphical configuration editor for approx This module provides a graphical configuration editor for /etc/approx/approx.conf. This editor is also able to upgrade configuration without user interaction. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Proposal to improve approx configuration upgrades
Hello Le jeudi 17 septembre 2009 14:11:01, Dominique Dumont a écrit : > So, I've written a wiki page [1] that explains: > - how configuration upgrade are managed by Config::Model > - how to implement such upgrades with Approx example: > * create a configuration model for approx.conf > * the patch required for approx package scripts In order to minimize the modifications to apply to approx package, I've created the libconfig-model-approx package, so now there's no need to ship approx.conf configuration model in approx package. The patch for approx is much simpler (See attachment): * a call to config-edit in postinst script * a new dependency on libconfig-model-approx-perl Now what's next? Can I submit a bug to approx package to push this idea further? Eric, what do you think ? All the best [1] http://wiki.debian.org/PackageConfigUpgrade -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Proposal to improve approx configuration upgrades
Le mardi 6 octobre 2009 17:09:05, Dominique Dumont a écrit :
> The patch for approx is much simpler (See attachment):
Ahem, here's the patch in attachment. Sorry.
All the best
diff -Naur approx-4.0/debian/approx.postinst approx-dev/debian/approx.postinst
--- approx-4.0/debian/approx.postinst 2009-06-30 18:16:45.0 +0200
+++ approx-dev/debian/approx.postinst 2009-06-30 18:23:10.0 +0200
@@ -34,4 +34,8 @@
fi
fi
+# upgrade user configuration
+# FIXME: upgrade requiring user interaction are not handled
+config-edit -model Approx -ui none -save
+
#DEBHELPER#
diff -Naur approx-4.0/debian/control approx-dev/debian/control
--- approx-4.0/debian/control 2009-06-30 18:16:45.0 +0200
+++ approx-dev/debian/control 2009-06-30 18:22:10.0 +0200
@@ -12,7 +12,7 @@
Package: approx
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${F:OCamlDeps}, lsb-base (>= 3.2), adduser, bzip2, curl, openbsd-inetd | inet-superserver, update-inetd
+Depends: ${shlibs:Depends}, ${misc:Depends}, ${F:OCamlDeps}, lsb-base (>= 3.2), adduser, bzip2, curl, openbsd-inetd | inet-superserver, update-inetd, libconfig-model-approx-perl
Description: caching proxy server for Debian archive files
Approx is an HTTP-based proxy server for Debian-style package archives.
It fetches files from remote repositories on demand,
Re: Proposal to improve approx configuration upgrades
Hello Eric Le mercredi 7 octobre 2009 13:09:06, vous avez écrit : > I don't really want to add a dependency on another package for such a > simple task. Simple, but it may be repetitive. Here a real life comment made by one of your users on #debian-perl: (03:02:23 PM) dusty: ddumont1: thanks for writing that doc. I didn't even know that existed. I may see about using it in my own packages. Your approx example really hits me because we use approx all over the place and have been hit with the recent (in the etch to lenny transition) changes to the config format of that file. It was always great fun to update our approx settings... whee. This kind of migration could be handled by config::model: the old syntax would be replaced by the new one. My patch would ensure that this upgrade is done at package upgrade time (although I arrived too late for Etch to Lenny migration :-p ) > Anyone deploying a caching proxy server should be able > to read a man page and edit a config file. That's a fair point. Approx users are not average users. > In general, if you want your approach to be adopted, I suggest making > it more separate from the packages themselves and more incremental. Yes, but the idea is to handle config upgrade during package upgrade. I do not know how this can be done outside of the upgraded package. > Perhaps you could follow the model of logcheck, or ifupdown -- > standardize on a directory that each package can put their scripts in, > so it works if your config tool is installed, but has no effect > otherwise. I'll have to think about it. I do not know how to trigger the execution of 'config-edit' this way. > Also, I haven't looked into either one in enough detail, but how does > your approach differ from ucf? ucf has a rather crude upgrade strategy: either accept upstream or keep your file or use your favorite editor. That's not very cool for average users. config-model is more subtle: upstream/packager data are merged with user data without user interaction. As a bonus, the user will get a GUI with integrated help to edit the configuration (I acknowledge that this may not be seen as a bonus for hardboiled sys admins ;-) ) All the best -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Proposal to improve approx configuration upgrades
Le mercredi 7 octobre 2009 21:13:45, Steve Langasek a écrit : > > ucf has a rather crude upgrade strategy: either accept upstream or keep > > your file or use your favorite editor. > > That's not true. ucf supports three-way merges. You're right. But three-way merge still requires the end-user to validate the merge. (Or to resolve conflicts). Config::Model can perform a similar task without user input. All the best -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Proposal to improve approx configuration upgrades
Le mercredi 7 octobre 2009 13:09:06, vous avez écrit : > I don't really want to add a dependency on another package for such a > simple task. Anyone deploying a caching proxy server should be able > to read a man page and edit a config file. Ok. Looks like you're not convinced... Could you at least: - add libconfig-model-approx-perl in Suggest: - mention in the doc that configuration and upgrade can be done with config- edit-approx provided by libconfig-model-approx-perl. On my side, I will enhance Approx parser to ensure that old approx conf files (etch) can be upgraded to new approx file format (addition of '$' prefix where needed). Is there any other old approx upgrade issue to take care of ? All the best -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Using a perl lib from postinst
On Wednesday 11 November 2009 20:16:08 Rodolphe Quiedeville wrote: > I would like to use a perl lib included in postgresql-common from a > postinst script. What have I to do ? I assume you want to call this perl lib from a postinst outside of postgresql- common package. > Call directly from the postinst or > write a perl script called from postinst ? I'm not sure what you mean. Since the postinst is a shell script, you cannot call directly the perl lib. You can either write a small perl script or use a perl one-liner. In all case, you will have to make sure that postgresql-common is installed when your postinst is called. HTH -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: FOSDEM 2010
On Saturday 28 November 2009 15:50:37 Wouter Verhelst wrote: > For those of you who were waiting for a call for talks from me on this > subject, it's not really coming. However, if you think your talk may be > of some interest to people working on distributions (Debian or > non-Debian), your talk should be welcome. I can provide a talk on better ways to handle configuration upgrades during packages upgrade [1]. These ideas can also be applied to other distros, so they should interest FOSDEM people. I also have some ideas about addressing ISV packaging needs but they are not fleshed out enough for a talk. May be a meeting between people having a similar goal ? Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: FOSDEM 2010
Oops, I forgot the link [1] in my previous mail. Sorry. [1] http://wiki.debian.org/PackageConfigUpgrade Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
dh_config_model_upgrade: package upgrade with Config::Model
Hello
The last version of libconfig-model-perl (640-3) is now shipped with
dh_config_model_upgrade.
The aim of dh_config_model_upgrade is to provide an easy way for a
debian developer to add better configuration upgrade to the packages
they maintain.
Let's assume that Joe, debian developer, wants to add smooth upgrade
capability to his foobar package.
What will the end user see ?
The end user may have to answer a medium debconf question asking him
whether to upgrade foobar package with Config::Model. Hopefully,
that's all the end user will see.
What does Joe, debian developer, has to do ?
- ensure that a proper configuration model for the application
contained in foobar exists.
- ensure that foobar.postinst and foobar.config have a #DEBHELPER#
line (if these files exist)
- ensure that foobar.control has a dependency on ${misc:Depends}
- ensure that call dh_config_model_upgrade during package build.
Either:
- run "dh --with config_model"
- directly call dh_config_model_upgrade. See
dh_config_model_upgrade man page for more details
(Simple instructions for CDBS should be provided. Help is welcome there)
How does this work ?
When called, dh_config_model_upgrade will setup foobar package to ask
whether to upgrade the configuration with Config::Model or not.
This requires to:
- add a dependency on libconfig-model-perl in foobar control file
- add or update foobar.config file so that the question is raised by
debconf. This file is generated from config-config-model delivered
by libconfig-model-perl package
- add or update foobar.postinst file so that the configuration is
upgraded if the user answered yes to the question above This file is
generated from postinst-config-model delivered by libconfig-model-perl
package
- last but not least, both foobar.config and foobar.postinst will use
a template delivered by libconfig-model-perl
(libconfig-model-perl.templates) to ask the question to user. This
template contains a ${pkg_name} substitution that will be replaced
with 'foobar' by foobar.config and foobar.postinst (See SUBST
debconf command in debconf-devel(7))
All these operations are handled by dh_config_model_upgrade.
For more informations, see http://wiki.debian.org/PackageConfigUpgrade
Config::Model home page is http://config-model.wiki.sourceforge.net/
User mailing list: http://sourceforge.net/mail/?group_id=155650
Comments are most welcome :-)
All the best
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dh_config_model_upgrade: package upgrade with Config::Model
On Friday 04 December 2009 11:18:46 Neil Williams wrote:
> The package version doesn't sound like a new project, who is using it
> (and why?).
Sorry, that's a typo. The version is 0.640-3. The project is new.
> (FYI the upstream CPAN description doesn't answer any of my questions
> below either. At no point is a Config Model explained or described or
> is any attempt made to explain *why* either the maintainer or the user
> would want this in use.)
Fair enough. I've updated the introduction of Config::Model wiki on
SourceForge. [1] I hope that this will convince you of the value of
Config::Model .
> Is this some kind of tasksel interface where the configuration is
> modelled on a particular end-user implementation type (like desktop vs
> server)?
There's no relation to apt tasksel.
> Is this an upstream configuration attempt that is trying to work in a
> downstream mode?
Err... Assuming I understand your question, this is an upstream project that
tries to help downstream packagers.
> Is it meant to just be one model per package or a unified model across
> all packages?
For now, it's one model per application that require a configuration. Package
without config must not use dh_config_model_upgrade
We can imagine to glue models together to provide system wide semantic
validation, (i.e. application A that must work with B is correctly configured
to work with B, and vice-versa), but we're not there yet.
> Just what is the point and what problem are you trying to solve?
The main goal is to lower the cost (in terms of time) of providing
configuration tools to end user. So that developers (or packagers) will be
able to afford the creation and maintenance of more graphical configuration
tools (with wizard, integrated help ...).
If we can manage that, I think that most casual users (i.e. non-geek) will be
grateful.
Another goal is to avoid casual users seeing things like this:
Configuration file `/etc/sensors3.conf'
==> File on system created by you or by a script.
==> File also in package provided by package maintainer.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : background this process to examine the situation
The default action is to keep your current version.
*** sensors3.conf (Y/I/N/O/D/Z) [default=N] ?
If my mother-in-law sees this, I'm sure to get a phone call ;-)
This can of situation can be handled automatically.
Using config-model could also help in reducing the number of lline of openssh-
server postinst script (480 lines) by removing the code dedicated to upgrades.
> > The aim of dh_config_model_upgrade is to provide an easy way for a
> > debian developer to add better configuration upgrade to the packages
> > they maintain.
>
> I read the announcement and the wiki page and I still don't understand
> the aim of the project - you describe the problem but I don't see how
> Config::Model solves anything and the existing "descriptions" don't
> actually explain what the Model is or why it would be useful.
I hope [1] will help in explaining the goal.
> From an embedded perspective, we certainly don't want every
> configurable package depending on perl at package installation /
> upgrade time - that's why we have cdebconf.
Embedded world has other constraint. Does the user often store configuration
data in embedded device ?
> This is especially important for packages with Priority higher than
> optional. If any of those packages start to use this, *I* am going to
> be the one who has to patch it out of them, so I need to know how to
> replace your code with a static configuration (created by the root
> filesystem management scripts) *and* disable the postinsts such that
> they can run without perl. ("Essential" has no meaning in embedded
> Debian - you might only have a reconfigured busybox, uclibc, a
> kernel and {a rebuilt} cdebconf as what Debian currently means by
> "Essential".)
dh_config_model is currently involved only with configuration upgrades.
It could also be used to generate at build time a generic configuration file.
But that's not the case right now. Would that help you ?
> It might be as simple as providing an empty shell script to replace
> dh_config_model *if* the system is sufficiently fault tolerant.
In this case, configuration files will simply be left as is. (which is also
the case if debconf variable libconfig-model-perl/automatic-upgrade is false)
> (In essence, your models *must* support not being implemented at all
> - bog standard, default configuration just as you get when telling
> debconf never to ask any questions. This is how packages are installed
> as build dependencies on the buildd's. For embedded purposes, the
> packages must also support exactly this config without /usr/bin/perl
> existing at all.)
I'm still not clear on how configurat
Re: dh_config_model_upgrade: package upgrade with Config::Model
Le vendredi 4 décembre 2009 10:57:51, Stefano Zacchiroli a écrit : > I wonder why the detail about how the conf file is being upgraded should > be relevant to the final user at all. As you observe on the wiki page, > most lusers barely know of the existence of /etc, why should they care > about Config::Model being used? Ideally, whether to use it or not is a > choice of the package maintainer. The idea was to offer the user a possibility to bail out since config-model is still experimental. But I'm beginning to wonder if this is a good idea... > > - ensure that a proper configuration model for the application > > contained in foobar exists. > > Exists where? Hmm, good point. I've added these explanation in libconfig-model-perl README.debian: - ensure that a proper configuration model for the application contained in foobar exists. Either: - find the package containing the relevant model in Debian (something like libconfig-model-foobar-perl) - find the package in CPAN and ask debian-perl team to package it - write the model. In this case, you may want to subscribe to config-model users list (see below) > It is not clear to me whether in Config::Model you have > the distinction between meta-models (that live in the Perl lib somehow) > and models that live in the package. The model for any application can be delivered either in a separate perl package (like libconfig-model-approx) or directly within the package. In the ebd, the model will be installed in the same place. There's no difference in the model itself. > On the same line, it is not clear to me whether the maintainer can > programmatically define updates other than "from model m_1 go to m_2". Most of the time, there won't be limitations on the number of model version you can jump. There will be limitations if the model evolves rapidly (i.e. the configuration semantics also evolve rapidly). This kind of fast evolution is generally avoided except for new projects. > Many thanks for your stubborn work on this! :-) :-} All the best Dominique (from home) -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dh_config_model_upgrade: package upgrade with Config::Model
Le vendredi 4 décembre 2009 19:00:55, Felipe Sateler a écrit : > Well, there is an abstract model of the config file. So yes, basically > it parses the file into an internal model. I believe the idea is to be > able to migrate automagically from one version to the next without user > intervention. If I'm wrong, please correct me. Because then I have the > same questions as you do :P. You're right. (short answer because I must look after the kids :-p ) all the best Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dh_config_model_upgrade: package upgrade with Config::Model
Le vendredi 4 décembre 2009 13:01:39, Stefano Zacchiroli a écrit : > My reading of the above quoted test, is that Config::Model is not > seeking to replace debconf; it is going to use it as other packages do > for interacting with the user. Or, to be more precise, my understanding > is that the package helper is going to prepare debconf questions that > will be shipped in the packages which use that helper. Correct. One possible extension to Config::Model is to use Debconf as a more generic interface. This could be used to generate Debconf question to fill missing mandatory values (as GUI or curses interface are generated at run time). I'm working on this, but it seems quite difficult to generate debconf question dynamically. Not to mention translation problems... All the best Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dh_config_model_upgrade: package upgrade with Config::Model
Le vendredi 4 décembre 2009 19:38:19, Neil Williams a écrit :
> That's a user change, I thought the point of this was that changes *not
> done by users* are causing problems. Different problem.
Currently, debian package will detect correctly if a user (or a script) left
the configuration unmodified and will upgrade the conf with the new file
coming from the package. This is perfectly fine.
As explained by gregoa, problem arise when a package script needs to keep
user's modifications and merge them with configuration data coming from new
packages.
Currently the only way to address this is to write ad-hoc code in the postinst
script. This is costly and often hard to maintain.
Another possibility is to perform three-way merge with ucf. This will often
succeed but not always: 3-way merge works at syntactic level and not semantic
level so it can often fails. For instance leaving duplicated config
parameters. and error prone.
Config::Model tries to fix this by performing the merge at semantic level.
> That's not how I understood the purposes of it, although it could be
> used that way, it isn't sufficient justification IMHO.
>
> If admins make changes, admins should expect to handle the dpkg
> conflicts.
This is where we disagree: admins are not the only users of Debian.
Config::Model tries to bring a solution for non-admin users. The kind of users
which are often comfortable on Ubuntu or Windows (yikes) because Ubuntu or
Windows tries to make thing easy for users (whether they succeed or not is
troll food and I will not express an opinion there :-p )
Config::Model tries to address 2 problems:
- configuration upgrade (which should be silent)
- application configuration (with the generated user interfaces)
I agree with you that experienced admins will not see a value in the GUI
("real men don't click") but the GUI will be welcome by casual users. IMHO,
Config::Model provides a way to generate these interfaces while no costing too
much to specify *and* maintain.
> I thought the idea of this was to handle changes not made by users - I
> think we agree that those instances are bugs.
To ease the user's life, Config::Model keeps users changes but also propagate
new data required by application evolutions.
> The postinst doesn't have to parse the conffile, it just has to not
> generate the dpkg result (by generating the conffile instead of
> packaging it) and allow the app to transition from one to the next.
This is not always the case. Hence some upgrade tools were written by Debian
(like ucf)
> If the existing file is different to what the package thinks it can
> upgrade, the package should not require dpkg to generate the error and
> the consequent halt of the package installation.
That a possibility which was choosen by RedHat. It's fine for servers, less so
for Desktops.
All the best
Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dh_config_model_upgrade: package upgrade with Config::Model
Le vendredi 4 décembre 2009 20:36:19, Joey Hess a écrit : > But it does seem likely that packages using it could fall back to > current config file handling if Config::Model were not available > in an embedded system. Agreed. That's a reasonable goal. Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dh_config_model_upgrade: package upgrade with Config::Model
Le vendredi 4 décembre 2009 20:08:57, gregor herrmann a écrit : > Since you speak French you might be interested in Dominique's > presentation at some French Perl meeting: > http://fpw2009.ubicast.eu/videos/free/64/ Today, I've recorded today an English version of this presentation (with some enhancements to the slide set). I should be able to make it available next week (I need to compress the 12GB DV file into something more manageable ;-) ) All the best Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dh_config_model_upgrade: package upgrade with Config::Model
Le vendredi 4 décembre 2009 17:48:00, Stefano Zacchiroli a écrit :
> Well, reading your posts I understand there is in fact a
> misunderstanding. The question mentioned in the reported wiki page has
> nothing to do with a debconf question: is the question posed by dpkg
> when there is a mismatch between an on-disk configuration file and the
> old version of the maintainer configuration file. Try re-reading the
> wiki page with that in mind to see if it makes a bit more sense (it does
> to me at least).
Well, I may have not been very clear about debconf usage with Config::Mode in
the Wiki.
I see 2 ways for Config::Model to use Debconf:
1. As proposed in the beginning of this thread, use debconf to ask a global
question whether to use Config::Model or not. As mentioned by Stefano, this is
a good idea. I agree (now) so I'll remove this part
2. Use Debconf to query missing configuration data (i.e. a mandatory value
without default value). But we're not there yet.
> > Where is the Model?
> > Who designs the Model?
>
> These are question I've posed my self already in the thread. Again, can
> we please leave the proposer the time to reply to those? Merely
> repeating the questions will not help :-)
In this case, the Model can be written by the upstream project, or by the
packager. But each model is dedicated to an application. I grant you that's
quite an effort, but not much more than writing a lens for Augeas. An Augeas
has already quite of lot of lenses written by the community. So this kind of
effort is possible by the same kind of community. Now, it's up to me to
convince this community that providing configuration upgrade ( and
configuration GUI ) is worth the effort.
> > 'Model' seems to be a completely misleading use of terminology. Why was
> > it chosen?
>
> I believe the author is using the model term in the same it is used in
> model-driven engineering [1]. *If* it is the case (I don't actually know
> if it is, but with that assumption in mind the terminology makes sense),
> a model is essentially an "abstract syntax tree"-like representation of
> a specific configuration file. Furthermore, classes of configuration
> file have a grammar in common (or "meta-model", in MDE terminology).
A model for Config::Model is to a configuration file what a schema is to an
XML file: a description of the structure and constraint of the semantic data
of the file.
That's big talk. So here's a very simple example extracted from Sshd model.
This example describes the TCPKeepAlive parameter:
'TCPKeepAlive' =>
{
'value_type' => 'enum',
'help' => {
'yes' => 'Send TCP keepalive messages. The server will notice if
the network goes down or the client host crashes. This avoids infinitely
hanging sessions.',
'no' => 'disable TCP keepalive messages'
},
'upstream_default' => 'yes',
'type' => 'leaf',
'description' => 'Specifies whether the system should send TCP keepalive
messages to the other side. If they are sent, death of the connection or crash
of one of the machines will be properly noticed. However, this means that
connections will die if the route is down temporarily, and some people find it
annoying. On the other hand, if TCP keepalives are not sent, sessions may
hang indefinitely on the server, leaving "ghost" users and consuming server
resources. This option was formerly called KeepAlive.',
'choice' => ['no','yes']
},
> > Is the model package specific or system-wide?
>
> According to the above assumptions, a model is just an abstract version
> of a specific config file, with some specific data in it.
> A meta-model is specific of a whole class of configuration files (e.g.
fstab, apache conf-file, postfix map file, etc.).
A configuration model is like a set of Class definition in C++, and the
configuration tree is an instance of the root class in the model. There are
like a set of configuration objects arranged in a tree structure from the
model (the set of classes)
All the best
Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dh_config_model_upgrade: package upgrade with Config::Model
Le vendredi 4 décembre 2009 19:46:04, Stefano Zacchiroli a écrit : > On Fri, Dec 04, 2009 at 06:54:56PM +0100, Dominique Dumont wrote: > > The idea was to offer the user a possibility to bail out since > > config-model is still experimental. But I'm beginning to wonder if > > this is a good idea... > > IMO it is not, in the sense that it is quite pointless to put this > choice on the final users. The choice about whether to use it or not > should be of the final *package maintainer*. If its use of config-model > works, fine, otherwise _his_ package will be considered RC buggy as any > other package erroneously fiddling with user conffile. Ok, I'll remove this question. > Please detail more the "write the model" case. I want that possibility, > but it is not clear to me whether the custom model can be shipped within > the package needing it at configuration time. (Yes, that of course > means that no-fiddling would be possible in preinst, but I got the > impression that it was already the case.) There are several possibilities: - either the model can be used also to configure the application. In this case, the model should contain help text (description, summary...) - or the model is used only in batch mode for upgrade. Since there's no user interaction, the help text can be skipped. In the first case, it's better to ship the model in a separate package and upload it to CPAN. Debian-perl team will then package it. In the second case, the model can be shipped only in the debian package. > No, that's was not my question, sorry if it was not clear; let me try > again. config-model will have a model for the previous maintainer > version of some conffile, let's call it m_1; then config-model can have > several other models m_2, ... m_n and it can jump up to m_n. > > What I want to know is whether config-model allows me not to write a > model m_i I'd like to arrive to in the package, but rather write a small > program snippet which takes m_1 and modify it in some way. That's > basically the different between "here is the model you should arrive to" > (which I understand is supported) and "here is a recipe/program to > obtain the model you should arrive to". I can easily add some code so that you can use config-model-edit (provided by Config::Model::Itself) in such a way. For instance if you want to change the default value of PermitRootLogin, you would need to run this line while packaging libconfig-model-openssh-perl: config-model-edit -model Sshd -save class:Sshd element:PermitRootLogin \ default=no Does this reply to your question ? Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dh_config_model_upgrade: package upgrade with Config::Model
Le dimanche 13 décembre 2009 17:48:13, Stefano Zacchiroli a écrit :
> Can I write my own upgrade script in Perl and have it play with
> the models involved in the upgrade (i.e., the old model and the new
> model) in the same scripts to migrate from one to the other in some
> ad-hoc way?.
>
Yes. Using Config::Model::Itself and some (untested) code like (please fasten
your seat belt):
my $meta_model = Config::Model -> new();
my $old_meta_inst
= $meta_model->instance (root_class_name => 'Itself::Model' ,
instance_name => 'old model' ,
);
my $old_meta_root = $old_meta_inst -> config_root ;
# create object to load model from files
my $old_rw_obj = Config::Model::Itself -> new(model_object => $old_meta_root);
# now load old model from old model files
$old_rw_obj -> read_all( model_dir => $old_model_dir,
root_model => 'SomeModel',
) ;
# serialise old model
my $old_dump = $old_meta_root->dump_tree;
# create new meta instance to hold new model
my $new_meta_inst
= $meta_model->instance (root_class_name => 'Itself::Model' ,
instance_name => 'new model' ,
);
# still empty model
my $new_meta_root = $new_meta_inst -> config_root ;
# copy old model in new instance
$new_meta_root->load($old_dump);
# customize new model
$new_meta_root->load('class:SomeModel element:foobar default="new default");
#create another rw object
my $new_rw_obj = Config::Model::Itself -> new(model_object => $new_meta_root);
# write the modified model somewhere else
$new_rw_obj -> write_all(model_dir => $new_model_dir,
root_model => 'SomeModel',
) ;
Depending on what you want to achieve, you may also directly modify the old
model in the program with:
$old_meta_root->load('class:SomeModel element:foobar default="new default");
and write the customised model files somewhere else as shown above.
HTH
Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
More on migration (was Re: dh_config_model_upgrade: package upgrade with Config::Model)
On Tuesday 08 December 2009 08:58:59 Stefano Zacchiroli wrote:
> Fair enough. So, in your terminology, a model is the schema. How do you
> call instances?
Well, I tend to use 3 entities in my doc:
- the model (perl data structures loaded in Config::Model object).
- Configuration instance (derived from a model). This instance contains a ref
to the root node of the confguration tree. This Config::Model::Instance also
holds some instance attributes (like whether to tolerate or not erroneous
values). Several instances can be attached to one model.
- Configuration tree (attached to one instance by the "root" node). The tree
is a structure of nodes (Config::Model::Node) with leaves
(Config::Model::Value). Let skip other details like hash or list elements.
> I'll use "instances" in the rest of this mail :-) Now
> that that is clear, which kind of migrations of configuration file can
> you provide on top of Config::Model.
All depends on the model and the related read and write methods. From that,
sevaral kind of migrations can be done:
- complete change of syntax (i.e. from INI file to YAML)
- Semantic changes (parameter name, default value ...). The more complex the
change, the more complex the model will become (the model must understand tghe
old structure, the new structure and provide the way to migrate from old to
new structures.)
If you want more details on migration, please provide a small use case, and
I'll be happy to provide a small example of a model with migration features.
> Given that models contain default values, I believe it would be pretty
> easy to provide change of default values, it would be enough to change
> them in m_{i+1}, right?
With one caveat: to preserve idempotency, there's must be no ambiguity on the
content of a parameter: so changing the semantic of a parameter without
changing its name will be difficult.
For instance if old model specifies:
timeout: value in minutes
and the new model specifies:
timeout: value in seconds
When loading the files, there's no way to know if the value is in minutes or
in seconds.
In this case, the new model must provide a new parameter name like:
timeout_s: value in seconds
In this case , the model can specify (in "pseudo-code"):
timeout_s = timeout * 60
> Still, my recurring question has left unanswered, I swear this is the
> last time I pose it. Does Config::Model permit to *programmatically*
> apply more complex modification at upgrade time?
Hmm, I may have badly understood your question before. Here's another approach
to handle upgrades.
> Let's say I want to, at
> the same time during an upgrade:
>
> - change a default value from "yes" to "no"
Heh, "default value" is a loaded notion ;-) There are in fact 2 cases to
cover:
- the default value is encoded by the application (what is called
"upstream_version" in Config::Model)
- the default value must be written in the config file (e.g. Debian's default
for ssh's PermitRootLogin).
The latter case is tricky because we can't know whether this value is provided
by a script (or Config::Model) or by a sysadmin. Debian policy specify to keep
sysadmin value.
That said, here's the migration scenario for case one:
PermitRootLogin => { type => 'leaf', value_type => boolean,
upstream_default => 0 }
New model will contain:
PermitRootLogin => { type => 'leaf', value_type => boolean,
upstream_default => 1 }
For case 2 where the default value must be written in the file (specify
"default" instead of "upstream_default"):
PermitRootLogin => { type => 'leaf', value_type => boolean,
default => 1 }
> - add 1 to a given set of integer values wrt what the user configured by
> hand (e.g. because there was an off-by-one sort of semantics in past
> upstream configuration, which has been changed now)
This one is more difficult because of the ambiguity mentioned above: what if
the user re-installs the package that tries to upgrade from old semantic to
new semantic ? The danger would be to get new = old +2 (or more...) thus
resulting to a bad value.
The only possibility would be to store somewhere the fact that the upgrade was
already done. If you factor in the fact that users do sometime downgrade a
package,this can lead to tricky situations.
In this case, I'd recommend changing the parameter name and use this kind of
model that include a migration:
old_param => {type => 'leaf', value_type => integer, status => 'deprecated'}
new_param => {type => 'leaf', value_type => integer,
migrate_from => { formula => '$old+1',
variables => { old => '- old_param' } ,
},
> The second case is a bit more tricky, because you can easily fix default
> values, but you really want to fix also user-customized values.
Problem is to distinguish between user-customized values and script-customized
values...
Re: dh_config_model_upgrade: package upgrade with Config::Model
Le vendredi 4 décembre 2009 12:35:30, Neil Williams a écrit : > Does Config::Model obey DEBCONF_NONINTERACTIVE_SEEN=true ? > > http://wiki.debian.org/Multistrap#Environment Once the debconf question is removed, Config::Model will be used in non- interactive mode (-ui none option) in postinst. All the best Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dh_config_model_upgrade: package upgrade with Config::Model
Le lundi 7 décembre 2009 04:19:34, Paul Wise a écrit : > It would still be nice if the postinst snippets didn't have to be > patched for EmDebian. I imagine this would simply mean checking for > perl in the postinst and only performing configuration upgrades when > it is available. Paul, during package build, removing the call to dh_config_model_upgrade from rules will remove dependencies on libconfig-model-perl and the config-model snippet from postinst. Is this enough for EmDebian ? Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dh_config_model_upgrade: package upgrade with Config::Model
On Wednesday 16 December 2009 17:40:55 Neil Williams wrote:
> No. The package should simply exit cleanly with a successful return
> value if perl does not exist, letting everything else proceed as before.
> The postinst itself needs to check - that way, Emdebian doesn't have to
> patch every package using dh_config_model.
Ok. Here's the new postinst snippet injected by dh_config_model_upgrade:
# In case of error (error in configuration file or model bug), the
# configuration file is left as is.
# testing perl is required to avoid problem in embedded environments
if [[ -e /usr/bin/perl ]]
then
echo "config-edit is upgrading %PACKAGE% configuration with model
%MODEL%."
config-edit -model %MODEL% -ui none -save %OPTION% || \
echo "WARNING: upgrade with config-edit failed: Run 'config-edit -model
%MODEL% -force %OPTION%' and save the configuration."
fi
Does this fit the bill ?
> An alternative is to make dh_config_model* into a no-op if a build
> environment variable is set. DEB_BUILD_OPTIONS="noconfigmodel" or
> something. With this set, it has to be entirely equivalent to
> dh_config_model not appearing in debian/rules at all.
Ok. Unless somebeody complains, I will add this at the beginning of
dh_config_model_upgrade:
if ($ENV{DEB_BUILD_OPTIONS} =~ /noconfigmodel/) {
warn "dh_config_model_upgrade: DEB_BUILD_OPTIONS specifies
'noconfigmodel',
exiting ...\n";
exit;
}
> It would be so much better if this whole implementation was in C - as
> long as nothing in the config model tried to execute the cross-built
> executable on the build system. Then the ability to disable it via a
> build option would be truly orthogonal to the actual issue of whether
> perl exists.
Well, a C implementation of the core part of Config::Model is possible, but it
would take a while to create. I don't have the bandwidth for this.
All the best
Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dh_config_model_upgrade: package upgrade with Config::Model
On Thursday 17 December 2009 14:24:48 Dominique Dumont wrote:
> Unless somebeody complains, I will add this at the beginning of
> dh_config_model_upgrade:
>
> if ($ENV{DEB_BUILD_OPTIONS} =~ /noconfigmodel/) {
> warn "dh_config_model_upgrade: DEB_BUILD_OPTIONS specifies
> 'noconfigmodel', exiting ...\n";
>exit;
> }
>
After reading (again) debhelper(7), I think it's better to exit silently if
DH_NO_ACT is set.
All the best
Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dh_config_model_upgrade: package upgrade with Config::Model
Le jeudi 17 décembre 2009 15:38:00, James Vega a écrit : > '[[' for testing is a bashism. This should be > > if [ -e /usr/bin/perl ] > > or more accurately > > if [ -x /usr/bin/perl ] Done. Thanks Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dh_config_model_upgrade: package upgrade with Config::Model
Le jeudi 17 décembre 2009 16:41:03, Carl Fürstenberg a écrit : > Will there be premade modules for the usual suspects? for example > Apache, INI, perl-hash, JSON, basic shell source, debcontrol/rfc-2822, > xml etc... There's already a generic parser and writer for perl-hash (more accurately perl data structure: nested hash and array) and INI. YAML is underway. JSON would be fast to add. With Augeas or libdebctrl (hi Jonathan), debcontrol would be quite easy to add. Apache config style is a tougher nut to crack as I must take care of included files. > Or is it meant that each package should reinvent the > wheel/copy-paste? No. Parsers and writers can be shared across several models. > Also I think there should be a "simple mode", there the model is only > defined for the general file format (as above), which can be activated > with only a commandline argument to dh_config_config_model, without > the need to write perl code/understand what a model is (not all devs > can this kind of thingis). This holds true for syntax. But how can a file be validated (from a semantic point of view) if there's no model, i.e. if there's no knowledge of what's supposed to be in the file ? (witjhout taking syntax into account) In fact, Augeas is much closer to what you are thinking about. But Augeas cannot provide configuration upgrade because there's almost no semantic knowledge in Augeas. Hope this helps Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dh_config_model_upgrade: package upgrade with Config::Model
Le jeudi 17 décembre 2009 20:48:50, Neil Williams a écrit : > DH_NO_ACT still needs debian/rules to be modified or else all debhelper > routines would be disabled; we need an option that is specific to > dh_config_model without having to edit debian/rules. > > I think DEB_BUILD_OPTIONS is still useful, whether or not > dh_config_model outputs the warning is neither here nor there for my > purposes. ok. dh_config_model_upgrade will react to both variables. > The debconf maintainers aren't the cdebconf maintainers; it's not > unusual for someone else to step up as long as the interface in the > perl version is suitable for porting to C. So the real issue is that > config::model tries hard to make an interface that can be implemented > in another language. Hmm. The core part of Config::Model could be rewritten in C: I've avoided using too many Perl magic. The fact that the models are currently stored as Perl data structure is not a big problem. This was done just as a convenience to parse quickly the models. The models could as well be stored as YAML, JSON or XML and used as is in a C implementation of Config::Model. The Perl implementation would just have to translate JSON or YAML or XML back as Perl data structure to work as usual. All the best Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
An English presentation about Config::Model and package upgrades
Le vendredi 4 décembre 2009 20:08:57, gregor herrmann a écrit : > Since you speak French you might be interested in Dominique's > presentation at some French Perl meeting: > http://fpw2009.ubicast.eu/videos/free/64/ For non-french speakers, I've recorded a new session in English. In this presentation, I've also talked about Augeas and package upgrades. Here are the slides : http://config-model.sourceforge.net/config-model-en.pdf And the video: http://config-model.sourceforge.net/config-model-2.avi (280MB) All the best Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#502543: ITP: confget -- Utility to read variables from a configuration file
Peter Pentchev <[EMAIL PROTECTED]> writes: > On Fri, Oct 17, 2008 at 05:48:02PM +0200, Adeodato Sim?? wrote: >> * Peter Pentchev [Fri, 17 Oct 2008 18:37:21 +0300]: >> >> > Description : Utility to read variables from a configuration file >> >> Please mention "INI-style" in the short description, eg.: >> >> Description : Utility to read variables from an INI-style >> configuration file > > Well, I will - for this version - but part of the idea behind confget is > that it will eventually grow the ability to read config files in other > formats. I had my sights set on Java property files, but it turned out > they were... a bit complicated, what with Unicode, quoting, and such, > so I left them out of 1.00. Then, you might want to consider Augeas for this purpose (Debian package are already available). Augeas has the ability to read and write INI files (and other files as well) See http://augeas.net for details HTH -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#509598: ITP: libconfig-model-tkui-perl -- Perl/Tk GUI to edit config data through Config::Model
Package: wnpp Severity: wishlist Owner: Dominique Dumont * Package name: libconfig-model-tkui-perl Version : 1.204-1 Upstream Author : Dominique Dumont * URL : http://search.cpan.org/dist/Config-Model-TkUI/ * License : LGPL Programming Lang: Perl Description : Perl/Tk GUI to edit config data through Config::Model This package provides a Perl/Tk interface to: - the configuration editor provided by Config::Model. - the configuration model editor provided by Config::Model::Itself For instance, with this module, Config::Model and Config::Model::OpenSsh, you get a graphical configuration editor for /etc/ssh/sshd_config. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509608: ITP: libtk-dirselect-perl -- Perl/Tk cross-platform directory selection widget
Package: wnpp Severity: wishlist Owner: Dominique Dumont * Package name: libtk-dirselect-perl Version : 1.11-1 Upstream Author : Michael J. Carman * URL : http://search.cpan.org/dist/Tk-DirSelect/ * License : Artistic Programming Lang: Perl Description : Perl/Tk cross-platform directory selection widget This module provides a cross-platform directory selection widget. A context menu (right-click or ) allows the creation, renaming, and deletion of directories while browsing. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#510723: ITP: libconfig-model-itself-perl -- Graphical *model* editor for Config::Model
Package: wnpp Severity: wishlist Owner: Dominique Dumont * Package name: libconfig-model-itself-perl Version : 1.208-1 Upstream Author : Dominique Dumont * URL : http://search.cpan.org/dist/Config-Model-Itself/ * License : LGPL Programming Lang: Perl Description : Graphical *model* editor for Config::Model This module provides a graphical editor to edit configuration model for Config:Model. (emphasis on model) This modules also provides a model for Config::Model (hence the Itself name, you can also think of it as a meta-model). The editor will use this meta-model to construct the graphical interface so you can edit the configuration model for *your* application. [ This module is the "eat your own dog food" principle applied to Config::Model ;-) ] Let's step back a little to explain. Any configuration data is, in essence, structured data. This data could be stored in an XML file. A configuration model is a way to describe the structure and relation of all items of a configuration data set. This configuration model is also expressed as structured data. This structure data is structured and follow a set of rules which are described for humans in Config::Model. The structure and rules documented in Config::Model are also expressed in a model in the files provided with Config::Model::Itself. Hence the possibity to verify, modify configuration data provided by Config::Model can also be applied on configuration models. Using the same user interface. The model editor program is config-model-edit. Since the model editor and the configuration data editor are based on the same graphical module, you will use similar UIs to edit configuration data (for instance Xorg configuration data from xorg.conf) and Xorg model (if you need to add new parameters in Xorg model) Once this module is installed, you can run: # config-model-edit -model For instance, if you have installed Config::Model::Xorg, you can run # config-model-edit -model Xorg If you save Xorg configuration model, it will create a lib directory and write the modified model there. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#510880: ITP: libconfig-model-cursesui-perl -- Curses interface to edit configuration data through Config::Model
Package: wnpp Severity: wishlist Owner: Dominique Dumont * Package name: libconfig-model-cursesui-perl Version : 1.102-1 Upstream Author : Dominique Dumont * URL : http://search.cpan.org/dist/Config-Model-CursesUI/ * License : LGPL Programming Lang: Perl Description : Curses interface to edit configuration data through Config::Model This module provides a Curses interface to the configuration editor provided by Config::Model. For instance, with this module, Config::Model and Config::Model::OpenSsh, you get a curses configuration editor for sshd_config. This interface is used by config-edit program provided by Config::Model. See also http://config-model.wiki.sourceforge.net/ -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#513016: ITP: libconfig-model-backend-augeas-perl -- Read and write configuration data through Augeas
Package: wnpp Severity: wishlist Owner: Dominique Dumont * Package name: libconfig-model-backend-augeas-perl Version : 0.102-1 Upstream Author : Dominique Dumont * URL : http://search.cpan.org/dist/Config-Model-Backend-Augeas/ * License : LGPL Programming Lang: Perl Description : Read and write configuration data through Augeas With Config::Model::Backend::Augeas, Config::Model now provides a way to load and save data through RedHat's Augeas library. Config::Model and Augeas are both configuration editing tool. Both parse configuration files in their native formats and transforms them into a tree. Configuration changes are made by manipulating this tree and saving it back into native config files. Both Augeas and Config::Model rely on a tree to represent configuration data. On one side, Augeas is able to load and write data while respecting the structure and comments of the original configuration file. But Augeas purpose is not to validate the semantic content of the configuration file. On the other side, Config::Model is able to validate the semantic content of the configuration file, but it will discard all comments and will write back configuration data using a canonical order. Thus the comments and structure of the original configuration file is not preserved. You can now have the best of both worlds by using the Augeas library to load and write data from Config::Model configuration tree. You can now instruct Config::Model to use Augeas backend in the autoread and autowrite feature. See Config::Model::Autoread for details. Unfortunately, you must ensure that the tree representation specified in Config::Model and Augeas lens are quite close together: - Config::Model element names and Augeas lens names must be identical - Both structures must be very close. Each Config::Model node must have a corresponsing lens. For more details on Config::Model see: http://config-model.wiki.sourceforge.net/ For more details on Augeas, see: http://augeas.net -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#576807: ITP: libdevel-perlysense-perl -- Perl IDE backend with Emacs frontend
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: libdevel-perlysense-perl Version: 0,0183-1 Upstream Author: Johan Lindström URL: http://search.cpan.org/dist/Devel-PerlySense/ License: Artistic and GPL Description: Perl IDE backend with Emacs frontend PerlySense is a Perl IDE backend that integrates with editor frontends, currently Emacs. (While no one has written a Vim frontend, PerlySense can emit Vim style data structures.) Conveniently navigate and browse the code and documentation of your project and Perl installation. Navigate between tests and source, and between related files. Search through the project for method declarations, invocants or free text using Ack. Run tests and scripts with easy navigation to errors/warnings/failing tests. Automate common editing tasks related to source code, tests, regular expressions, etc. Highlight syntax errors, warnings, Perl::Critic complaints, and Devel::Cover test coverage in the source while editing. PerlySense has a plugin system for understanding custom syntax, e.g. Moose. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004071354.09450.domi.dum...@free.fr
ITP: libfile-corresponding-perl -- Find corresponding files in the directory tree
Hello I've messed up while sending the ITP [1], so I'm manually forwarding it to debian-devel and debian-perl. I'll rework the full description before uploading this package. This package is a dependency of future package libdevel-perlysense-perl = Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libfile-corresponding-perl Version : 0.003 Upstream Author : Johan Lindstrom * URL : http://search.cpan.org/dist/File-Corresponding/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Find corresponding files in the directory tree File::Corresponding uses a configuration of groups of File Profiles to identify corresponding files. Using a .corresponding_file config file, and the command line script corresponding_file, you can easily look up corresponding files. It's obviously better if you let your editor do the tedious bits for you, like passing the file name to the script, letting you choose which of the corresponding files you meant, and opening the file in the editor. That's left as an exercise for the reader (well you are a programmer, aren't you?). == All the best [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578812 Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004280911.39462.domi.dum...@free.fr
Bug#597613: ITP: libdist-zilla-plugins-cjm-perl -- CJM's plugins for Dist::Zilla
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libdist-zilla-plugins-cjm-perl Version : 3.01 Upstream Author : Christopher J. Madsen * URL : http://search.cpan.org/dist/Dist-Zilla-Plugins-CJM/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : CJM's plugins for Dist::Zilla Collection of Dist::Zilla plugins. This package features the following Perl modules: * Dist::Zilla::Plugin::ArchiveRelease - Move the release tarball to an archive directory * Dist::Zilla::Plugin::GitVersionCheckCJM - Ensure version numbers are up-to- date * Dist::Zilla::Plugin::ModuleBuild::Custom - Allow a dist to have a custom Build.PL * Dist::Zilla::Plugin::TemplateCJM - Process templates, including version numbers & changes * Dist::Zilla::Plugin::VersionFromModule - Get distribution version from its main_module * Dist::Zilla::Role::ModuleInfo - Create Module::Build::ModuleInfo object from Dist::Zilla::File Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201009211256.17548.dominique.dum...@hp.com
Bug#597618: ITP: libdist-zilla-plugin-prepender-perl -- prepend lines at the top of your perl files
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libdist-zilla-plugin-prepender-perl Version : 1.101590 Upstream Author : Jerome Quelin * URL : http://search.cpan.org/dist/Dist-Zilla-Plugin-Prepender/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : prepend lines at the top of your perl files This Dist::Zilla plugin will prepend the specified lines in each Perl module or program within the distribution. For scripts having a shebang line, lines will be inserted just after it. This is useful to enforce a set of pragmas to your files (since pragmas are lexical, they will be active for the whole file), or to add some copyright comments, as the fsf recommends. Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201009211406.24151.dominique.dum...@hp.com
Re: Renaming a conffile in maintainer scripts
On Friday 08 October 2010 15:38:22 Raphael Hertzog wrote: > While this avoids the conffile prompt in all cases, it also means that if > the new conffiguration file has changes compared to the old one, the user > doesn't get to see them... instead they are stored in .dpkg-new without > any prompt. Which brings the question: how can we be sure that the user should not be notified of configuration changes introduced by the package maintainer ? > BTW, .dpkg-new is an extension used by dpkg to unpack new versions of > files during dpkg --unpack. So it will be automatically removed in the > next upgrade of that package... because the hash of the distributed file > has not changed and hence it believes that nothing needs to be done. > > At the very least, I think we should move in .dpkg-dist to be > consistent with what dpkg would have done if the user had seen a prompt > and answered to keep his old file. Do you agree with this? Currently, *.dpkg-dist means that some changes happened that were important enough to trigger a prompt. If they cannot be distinguished from *.dpkg-new, sys admin will not be able to focus on more important changes. May be we'd need to distinguish - after upgrades - new conf files with important changes from new conf files with trivial changes (e.g. comments) > But can we do better and somehow find out the hash on the new conffile > during the preinst (inspecting /var/lib/dpkg/info/tmp.ci/ maybe?) so that > we can put the old conffile in place of the new when we know that it would > have resulted in a prompt anyway? Sorry, you lost me there. Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201010111007.59930.dominique.dum...@hp.com
DEP5 CANDIDATE parser/editor/validator/migrator is released in libconfig-model-perl
Hello
The new version of libconfig-model-perl 1.229 is now available in Sid. This
new version provides a model of DEP-5 updated according to the CANDIDATE
version. (Among other features [1], like editor/validator for debian/control).
The DEP-5 editor must be run in the source package directory (I'll provide an
example below) with the following command:
config-edit -application dpkg-copyright
Features:
* check copyright file (with option "-ui none")
* migrate from old format to new format ( with option "-ui none -save")
* graphical editor (no option, but libconfig-model-tkui-perl must be installed)
Known issues:
- some keywords from older versions of DEP-5 specs may have been missed.
In this case, feel free to send a mail to config-model-users mailing
list or to log a bug in BTS.
- the update of the content of the format string is silent. This behavior
is a bit cavalier. This will change in the next version.
Example:
The copyright file of libconfig-model-backend-augeas-perl need to be updated:
Here's the original copyright file (slightly edited to protect my mail box
and save electrons) :
$ cat debian/copyright
Format-Specification:
http://wiki.debian.org/Proposals/CopyrightFormat?action=recall&rev=196
Upstream-Maintainer: Dominique Dumont (ddumont at cpan.org)
Upstream-Source: http://search.cpan.org/dist/Config-Model-Backend-Augeas/
Upstream-Name: Config-Model-Backend-Augeas
Copyright: 2008-2009, Dominique Dumont (ddumont at cpan.org)
License: LGPL-2+
Files: debian/*
Copyright: 2009, Dominique Dumont
License: LGPL-2+
License: LGPL-2+
This program is free software; you can redistribute it and/or
[snip]
First, let's just check issues:
$ config-edit -application dpkg-copyright -ui none
Element 'Upstream-Maintainer' of node 'Debian::Dpkg::Copyright' is deprecated
Element 'Upstream-Source' of node 'Debian::Dpkg::Copyright' is deprecated
Element 'Upstream-Name' of node 'Debian::Dpkg::Copyright' is deprecated
Missing 'Files:' specification at top of section number 2. Adding 'Files: *'
spec
Then, let's see what's config-edit can fix all by itself:
$ config-edit -application dpkg-copyright -ui none -save
[ same warnings displayed ]
Let's check the result of the migration:
$ config-edit -application dpkg-copyright -ui none
[ good: no more warnings ]
And here's the content of the upgraded file (drum rolls, please):
$ cat debian/copyright
Format: http://dep.debian.net/deps/dep5/
Upstream-Name: Config-Model-Backend-Augeas
Upstream-Contact: Dominique Dumont (ddumont at cpan.org)
Source: http://search.cpan.org/dist/Config-Model-Backend-Augeas/
Files: *
Copyright: 2008-2009, Dominique Dumont (ddumont at cpan.org)
License: LGPL-2+
Files: debian/*
Copyright: 2009, Dominique Dumont
License: LGPL-2+
License: LGPL-2+
This program is free software; you can redistribute it and/or
[snip]
You can see that:
- keywords were changed while keeping the correct content
- Format: was updated with the right URL
- "Files: *" line was added in the right place
Please provide feedback!
If you have problem migrating DEP5 files, yell, and we'll fix them.
If this migration works fine, don't be shy, please say so.
Under the hood:
Most of the migration work is specified in DEP-5 model [2]. Using
config-model's GUI [3] to update DEP-5 model, about one hour was
spent to:
- flag old parameters as deprecated
- introduce new parameters from candidate version (mostly done by
cut'n'paste old parameters into their new name, done within the
model editor GUI )
- cut'n'paste the doc bits from the web page into the model editor GUI
- specify migrate_from instruction to copy semantic content from old
parameters to new ones. (*)
This shows one important feature of Config::Model: maintenance and evolution
of a model is not a huge task. Even though copyright files are not configuration
files, the same approach can be used to specify model and migration of other
configuration files.
Now comes the question of the migration as seen by the user. Well, it's your
turn now.
Try it and tell us how it works!
Hopefully, encouraged by your feedback, other people will apply config-model to
other
specifications or other configuration.
All the best
[1] http://cpansearch.perl.org/src/DDUMONT/Config-Model-1.229/ChangeLog
[2]
http://cpansearch.perl.org/src/DDUMONT/Config-Model-1.229/lib/Config/Model/models/Debian/Dpkg/Copyright.pl
[3] config-model-edit -model Debian::Dpkg::Copyright provided by
libconfig-model-iteslf-perl
http://freshmeat.net/projects/config-model-itself/
(*) E.g, in the text format produced by the model editor GUI:
'Upstream-Contact',
{
'value_type' => 'string',
Re: DEP5 CANDIDATE parser/editor/validator/migrator is released in libconfig-model-perl
On Thursday 13 January 2011 15:06:56 Picca Frédéric-Emmanuel wrote: > Here the messages I got when checking my guidata package (already in the > new queue) > > picca at grisette:~/Debian/guidata/guidata$ config-edit -application > dpkg-copyright -ui none > You should install Config::Model::TkUI or > Config::Model::CursesUI for a more friendly user interface Note to self: suppress this warning when -ui is none > Warning in > 'License': key 'CeCILLv2' should match > ^(?i:Apache|Artistic|BSD|FreeBSD|ISC|CC-BY|CC-BY-SA|CC-BY-ND|CC-BY-NC|CC-B > Y-NC-SA|CC-BY-NC-ND|CC0|CDDL|CPL|Eiffel|Expat|GPL|LGPL|GFDL|GFDL-NIV|LPPL|M > IT|MPL|Perl|PSF|QPL|W3C-Software|ZLIB|Zope)[\d\.\-]*\+?$ Note that this message is just a warning. > Element 'Format-Specification' of node 'Debian::Dpkg::Copyright' is > deprecated This warning is normal when migrating older copyright files > In configuration root: (function 'create_element') unknown > element 'Upstream-Author' (configuration class 'Debian::Dpkg::Copyright') This one is more problematic and is the real cause of config-edit failure. That's one of the older keywords I did not know about. I will add it as a deprecated parameter for the next release. Its content will then be moved to Upstream-Contact parameter. In the meantime, you can shoudl update this parameter with your favorite editor. > Expected: > 'Format','Upstream-Name','Upstream-Contact','Source','Disclaimer','Comment > ','Copyright','Files','License','Format-Specification','Name','Maintainer', > 'Upstream-Maintainer','Upstream-Source' or an acceptable parameter matching > 'X-.*' > > > So it seems that the CeCILLv2 licence (sort of french GPL licence) [1] is > unknown of your software:) Add thoses licences to the licences keys whould > be a good things ?. At the end how many licences keys ? DEP5 model knows the list of keywords specified in DEP5 [1], which are the most commonly used. There's currently a long thread in debian-project list about managing the license keywords. In your case, either this keyword must be added to the list in DEP5 or you can choose to ignore the warning. Thanks for trying config-model and for your feedback :-) [1] http://dep.debian.net/deps/dep5/#index6h1 In theory. In practice, I've just noticed that my list of licence keywords is not accurate :-/ I'll fix this ASAP. Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101131553.14848.d...@komarr.gre.hp.com
Re: DEP5 CANDIDATE parser/editor/validator/migrator is released in libconfig-model-perl
On Thursday 13 January 2011 16:38:31 Steve Langasek wrote: > Please make your model recognize when a stand-alone license stanza is > present which defines a new license name in the file. DEP5 is not > intended to have an authoritative list of all licenses in use, only the > common ones; Currently, unknown keyword are accepted with a warning. The only other solution is to accept unknown keyword *without* warning (i.e. silently). Is this what you want ? > still, we do need validating parsers to recognize when > there's an undefined reference to a license name that's not defined in the > file. That's currently provided. All the best. Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101131651.54193.d...@komarr.gre.hp.com
Re: DEP5 CANDIDATE parser/editor/validator/migrator is released in libconfig-model-perl
On Thursday 13 January 2011 16:35:06 Picca Frédéric-Emmanuel wrote: > I attached the copyright file Interesting. Your file is formatted according to the spec archived on Debian wiki. Looks like this spec was done before the DEP-5 work begun. Since then, some fields like Debianized-* were dropped. I guess that the migration sped of DEP-5 model should also arrange to drop these fields... I've added your file to the non reg test. I'll fix this ASAP > See you Sure :-) All the best Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101131752.35751.d...@komarr.gre.hp.com
Re: DEP5 CANDIDATE parser/editor/validator/migrator is released in libconfig-model-perl
On Thursday 13 January 2011 22:27:02 Joey Hess wrote: > Thanks for your work, here are a few things I stumbled on. Thanks for trying and reporting issues :-) > Worst problem: -save *removes* all Comment fields except for one > in the header section. Looks like I messed up the routine that transform a file written with dpkg syntax into a data structure (list of list). I'm working on it. > Also, -save converted in the header "Disclaimer:\n Foo" into "Disclaimer: > Foo". If I'm reading DEP-5 right, that's not correct, the Disclaimer is > not supposed to have a synopsis. That is also done for a Comment field in > the header section. > > Also, note that "Comment: foo" is not flagged as a problem (despite > being apparently illegal -- DEP-5 puzzlingly does not allow a comment > to have a synopsis). Now that I have finally understood this notion of synopsis, I can fix these issues. > With -save, two trailing license blocks with identical content got > reordered, which was surprising. Licences sections are written back using an alphabetical sort of the short licence names. > (I dislike that DEP-5 seems to require > I duplicate content here; I considered making the second block say "See > above", but it seems likely it could be presented out of order by some > future tool.) Actually, the full text of GPL-2 and GPL-2+ should be slightly different. The latter should mention something like "version 2 or above". From a legal point of view, I guess that point should be spelled out explicitly and not only implied by the "+" at the end of the short name. But this point is more Lars' territory than mine ;-) > The following seemed to be caused by a Comment field at the end of a > section. I had to move it to above the License field. That was a bug in dpkg parser. This is fixed now (well, on my laptop...) > Missing 'Files:' specification at top of section number 4. Adding 'Files: > *' spec Configuration item 'Files:* License short_name' has a wrong value: > license other is not declared in main Licence section. Expected GPL-2 > GPL-2+ zsh: exit 25config-edit -application dpkg-copyright -ui none > -save Since the license short names are a fuzzy moving target, I'm more and more tempted to drop the warning in case of unknown keyword. > Unfortunatly I didn't preserve the input that caused this crash: > > joey@gnu:~/src/moreutils>config-edit -application dpkg-copyright -ui none > You should install Config::Model::TkUI or Config::Model::CursesUI for a > more friendly user interface Can't call method "fetch_element" on an > undefined value at > /usr/share/perl5/Config/Model/Backend/Debian/Dpkg/Copyright.pm line 111. This is probably due to the dpkg parser problem. We'll see if this problem happens again. All the best Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101141417.44636.d...@komarr.gre.hp.com
Re: DEP5 CANDIDATE parser/editor/validator/migrator is released in libconfig-model-perl
On Thursday 13 January 2011 22:48:48 Joey Hess wrote: > Also, it's missing BSD-2-clause etc. ok. Fixed. Unless I remove all these license keyword check... Still thinking ... > The original format from the wiki page uses comma to separate > Files. Might be worth detecting and converting those? Done. All the best Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101141436.55511.d...@komarr.gre.hp.com
Re: DEP5 CANDIDATE parser/editor/validator/migrator is released in libconfig-model-perl
Le dimanche 16 janvier 2011 13:48:55, Charles Plessy a écrit : > Given that there are only 9 different fields in the current DEP-5 syntax, I > think that parsers can simply incorporate the full list of them rather than > rely on a X- prefix to determine if a field is in the specification or not. Sure. The only hitch is that the parser cannot distinguish between an extra field and a typo. All the best. Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101161613.24844.domi.dum...@free.fr
Re: DEP5 CANDIDATE parser/editor/validator/migrator is released in libconfig-model-perl
Hello Frédéric On Thursday 13 January 2011 16:35:06 Picca Frédéric-Emmanuel wrote: > hello, another try :) > > picca@grisette:~/Debian/tango/tango$ config-edit -application > dpkg-copyright -ui none You should install Config::Model::TkUI or > Config::Model::CursesUI for a more friendly user interface 2011/01/13 > 16:30:47 Invalid line: Copyright : � 1997-1999 AT&T Laboratories Cambridge > > 2011/01/13 16:30:47 Invalid line: Copyright : � 2010, The Tango team > > [etc ...] I've modified Config::Model's DEP5 model and parser to parse *most* of your file. It has still some syntax issues that must be fixed manually: - a missing ':' after a Licence keyword - missing ' .' line between licence paragraph Note that your copyright file mixes UK and US spelling for "licence". UK spelling is converted to US spelling (used in DEP5 text). This will be part of v 1.230 of config::Model. All the best Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101201427.56142.d...@komarr.gre.hp.com
Re: DEP5 CANDIDATE parser/editor/validator/migrator is released in libconfig-model-perl
On Thursday 13 January 2011 23:54:04 Charles Plessy wrote: > By the way, Dominique, some licence version numbers can contain > alphanumeric characters. For instance the LaTeX project public license, > version 1.3c. Given that License keywords are fuzzy, moving targets. I've dropped any attempt at warning for unknown license keyword. OTOH, license keyword without matching full text will trigger an error. All the best Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101201437.44972.d...@komarr.gre.hp.com
Re: DEP5 CANDIDATE parser/editor/validator/migrator is released in libconfig-model-perl
On Saturday 15 January 2011 17:04:30 Joey Hess wrote: > One more thing, "License: GPL-2+ | Expat" was an old syntax on the wiki, > and it seems the parser only looks for an expansion of the GPL-2+ > license in this case, ignoring the Expat part. That was a bug in the Parse::RecDescent grammar snippet use to check license keyword line. That's fixed now. Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101201439.45394.d...@komarr.gre.hp.com
Re: DEP5 CANDIDATE parser/editor/validator/migrator is released in libconfig-model-perl
On Thursday 20 January 2011 15:33:17 Adam Borowski wrote: > On Thu, Jan 20, 2011 at 02:27:55PM +0100, Dominique Dumont wrote: > > On Thursday 13 January 2011 16:35:06 Picca Frédéric-Emmanuel wrote: > > > 16:30:47 Invalid line: Copyright : � 1997-1999 AT&T Laboratories > > > Cambridge > >^ > Aren't those supposed to be UTF-8 encoded? They are encoded in utf-8 in the file provided by Frédéric. Above has been messed up by some mailer somewhere. Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101201559.01973.d...@komarr.gre.hp.com
Re: DEP5 CANDIDATE parser/editor/validator/migrator is released in libconfig-model-perl
On Friday 21 January 2011 14:32:54 Thomas Preud'homme wrote: > > 2011/01/13 16:30:47 Invalid line: Copyright : � 2010, The Tango team > > > > Could it be because of the space between Copyright and the colon? Yes. That was not recognized by the Dpkg syntax parser. This is now accepted but corrected when the copyright file is written back (-save option) > > Element 'Format-Specification' of node 'Debian::Dpkg::Copyright' is > > deprecated In configuration root: (function 'create_element') unknown > > element 'Upstream-Author' (configuration class 'Debian::Dpkg::Copyright') > > Expected: > > 'Format','Upstream-Name','Upstream-Contact','Source','Disclaimer','Commen > > t > > ','Copyright','Files','License','Format-Specification','Name','Maintaine > > r', 'Upstream-Maintainer','Upstream-Source' or an acceptable parameter > > matching 'X-.*' > > I guess you don't have a problem with this one. Upstream-Author is now recognized as a deprecated keyword and translated in Upstream-Contact. All the best Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101211547.29180.dominique.dum...@hp.com
New version of DEP-5 parser
Hello I've fixed upstream [1] most (hopefully all) the issues regarding the DEP5 parser based on Config::Model that were mentioned on these lists or in the BTS. The new version is already (thanks gregoa) available on Debian/Sid in libconfig-model-perl 1.230 I've updated the parser so as to upgrade older version of copyright file (even pre DEP-5 versions) into the current format. All old keywords are translated into new keywords (except the old keywords I do not know yet about :-p ) For those who missed the previous thread, you can find more details in my blog [2]. Last but not least, I'll present Config::Model and its applications (including OpenSsh config and DEP-5 copyright) in the cross-distro dev room at FOSDEM in 2 weeks. Feel free to come by and let's discuss DEP5 or other possible applications. All the best Dominique [1] http://search.cpan.org/dist/Config-Model/ [2] http://ddumont.wordpress.com/2011/01/13/debian-copyright-dep5-parsereditorvalidatormigrator-is- released/ -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101212116.59690.domi.dum...@free.fr
Re: New version of DEP-5 parser
Le vendredi 21 janvier 2011 22:18:18, Steve Langasek a écrit :
> Not having looked at the code, I'm wondering: do you apply these
> translations to all files regardless of the Format/Format-Specification
> field's value, or are you selective about only applying these upgrades to
> fields that were considered valid at the time?
It's not selective. The model [1] that defines the behavior during the upgrade
is purely declarative.
Config::Model was designed to handle configuration files where the concept of
unknown parameter does not apply.
> I don't think, for
> instance, that a file that has a declaration of Format:
> http://dep.debian.net/deps/dep5/ [1] should have 'Maintainer' fields
> auto-upgraded to 'Upstream-Contact', but that this should instead be
> treated as an unknown field.
Like others, the history of this parameter is complicated. It was required,
then deprecated, and now legal (but with a possibly different semantic
content). If you factor in the possibility of human error (e.g. modern
format, but forgotten Maintainer field), having a DEP-5 validated file
may not mean much.
For instance, this DEP-5 file is valid, since Maintainer field
is accepted as an unknown parameter and Upstream-Contact is optional:
Format: http://dep.debian.net/deps/dep5/
Maintainer: foo@bar
Files: *
Copyright: (c) me
License: GPL-2+
This program is free software; you can redistribute it
and/or modify it [snip]
In this case, is this an error or a DD who does not
like the Upstream-Contact keyword ?
Note that the debian policy is respected since the upstream
info is provided. But the original objective of DEP5
("facilitate automated checking and reporting of licenses
for packages and sets of packages) is in jeopardy.
If the consensus is that such a Maintainer field should be left
as is, one solution would be to keep the current model with its upgrade
capability and provide another pure dep-5 model.
Then the user would to choose between:
- the dep-5-model-with-upgrade (and a few drawbacks like
deprecated Maintainer fields)
- a pure dep-5 without migration
I'll provide the latter if people ask for it for actual use.
All the best
Dominique
[1]
http://cpansearch.perl.org/src/DDUMONT/Config-Model-1.230/lib/Config/Model/models/Debian/Dpkg/Copyright.pl
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201101231509.01093.domi.dum...@free.fr
Bug#611189: ITP: libmodule-metadata-perl -- Gather package and POD information from perl module files
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libmodule-metadata-perl Version : 1.03 Upstream Author : David Golden , Ken Williams , Matt S Trout (mst) , Randy W. Sims * URL : http://search.cpan.org/dist/Module-Metadata/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Gather package and POD information from perl module files Module::Metadata provides routines to gather information about perl modules, like name, version, list of packages, list of pod sections... This module is required to update Dist::Zilla::Plugins::CJM Dominique Dumont -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101261614.03467.domi.dum...@free.fr
Bug#611651: ITP: libpod-wordlist-hanekomu-perl -- Add words for spell checking POD
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libpod-wordlist-hanekomu-perl Version : 1.110090 Upstream Author : Marcel Gruenauer * URL : http://search.cpan.org/dist/Pod-Wordlist-hanekomu/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Collection of stop-words for POD spell check Pod::Wordlist::hanekomu contains a list of words commonly found in POD docementation. When Pod::Wordlist::hanekomu is loaded, this words are added as stopwords to Pod::Spell. Which means that these words will be ignored by the spell checker. Enhances: libpod-wordlist-perl, libpod-spell-perl This is a dependency of future package libdist-zilla-plugin-podspellingtests-perl Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101311811.38805.domi.dum...@free.fr
Re: New version of DEP-5 parser
Le mardi 22 février 2011 19:06:27, vous avez écrit : > Can't call method "fetch_element" on an undefined value at > /usr/share/perl5/Config/Model/Backend/Debian/Dpkg/Copyright.pm line 121. > > Do you want me to fill a bug report in addition to this email? Yes, please. And also include the copyright file (or an extract) that shows the bug. All the best Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110024.03068.domi.dum...@free.fr
Re: Are circular dependencies inside a source package OK?
Le dimanche 27 février 2011 16:31:29, Lucas Nussbaum a écrit : > But then, we have a problem, because: > - ruby-foo need one of (ruby1.8-foo, ruby1.9.1-foo, jruby-foo, > rubinius-foo) installed to work correctly ok > - ruby1.8-foo, ruby1.9.1-foo, jruby-foo, rubinius-foo need ruby-foo > installed Correct me if I'm wrong, but ruby1.8-foo, ruby1.9.1-foo, jruby-foo are not broken without ruby-foo, they're just useless. So this may be interpreted as not being a dependency. Moreover, I have the impression that any ruby package needing foo *functionality* will depend on ruby-foo and not on any arch/interpreter specific package. In this case the dependency between ruby1.8-foo, ruby1.9.1- foo, jruby-foo, rubinius-foo will probably never be actually used .. Thoughts ? HTH Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201103012235.46134.domi.dum...@free.fr
Bug#617937: ITP: libmousex-strictconstructor-perl -- Make your object constructors blow up on unknown attributes
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libmousex-strictconstructor-perl Version : 0.02 Upstream Author : Fuji, Goro (gfx) * URL : http://search.cpan.org/dist/MouseX-StrictConstructor/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Make your object constructors blow up on unknown attributes Simply loading this module makes your constructors "strict". If your constructor is called with an attribute argument that your class does not declare, then it dies. This is a great way to catch small typos. Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201103121917.55793.domi.dum...@free.fr
Who is (co-)maintaining lcdproc package ?
Hello lcdproc package in Debian is outdated. I've prepared and uploaded in mentors an up-to-date package starting from the last version prepared by Nick (thanks Nick). In this package, lcdproc's maintainer is still Jose and Jonathan is listed as uploaders. Is this still valid ? Jose, so you want to resume maintaining lcdproc or do you want another one to take over ? Jonathan, as a DD, can you sponsor the new package ? Nick, do you want to be listed as uploaded ? Depending on your answers, I'll upload a new version with an updated maintainer/uploader list. (and with a correction in the bug list which is missing commas) All the best Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ signature.asc Description: This is a digitally signed message part.
Bug#514013: ITP: libconfig-model-openssh-perl -- Graphical editor for OpenSsh sshd_config and ssh_config files
Package: wnpp Severity: wishlist Owner: Dominique Dumont * Package name: libconfig-model-openssh-perl Version : 1.203 Upstream Author : Dominique Dumont * URL : http://search.cpan.org/dist/Config-Model-OpenSsh/ * License : LGPL Programming Lang: Perl Description : Graphical editor for OpenSsh sshd_config and ssh_config files Config::Model::OpenSsh provides a graphical configuration editor for /etc/ssh/sshd_config and /etc/ssh/ssh_config (for root) and ~/.ssh/config for non-root users. Once this module is installed, you can run: # config-edit-sshd Likewise, you can edit your ~/.ssh/config file with: $ config-edit-ssh Or to edit /etc/ssh/ssh_config, run as root: # config-edit-ssh With libconfig-model-cursesui-perl, you can also use a curses interface. With libconfig-model-backend-augeas-perl, you will use Augeas to keep comment and structure of /etc/ssh/sshd_config (not available for ssh config data) Config::Model::OpenSsh include a configuration model that describe the structure and constraints of OpenSsh configuration. This model is used by Config::Model to generate the graphical or curses interfaces. This model can also be used as an example for developers who would like to create their own configuration model for their project. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Proposal to improve package configuration upgrades
[ this discussion was started on debian-perl. I'm restarting it on debian-devel following Gregor Hermann suggestion ] Hello The other day, I was upgrading cups and dpkg did ask me the usual way if I wanted to keep my cups config file or take the upstream version. Like always, I asked for a diff and was quite puzzled because I did not remember anything about editing this file. Then I remembered that I did a modification through cups admin web interface. Previous common story you might say. But for a casual user (like my mother-in-law which now use Debian Lenny ;-) ), this can be frustrating: - I did modify the config through a nice web interface - during the upgrade, I either have to look at all the gory details of the config file or I have to loose my configuration. So I was thinking that this is a typical case where the upgrade could be smoothly handled by Config::Model. Either in automatic mode where user data and upstream modifications are merged (*) or in manual mode where the graphical (or curses) interface is fired up so the user can check what's going on. Of course, there's no miracle. For the merge to work automatically and the result to be valid, the semantic of the configuration file must be known by Config::Model. This is done by describing the structure and constraints of the configuration file in a model (hence the Config::Model name). What do you think about this ? All the best (*) If you want I can go more in details on how an upgrade can be done -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Proposal to improve package configuration upgrades
Jonas Smedegaard writes: > Do Config::Model support migration from one model to another? Yes. In fact model version n can include specific attribute to deal with migration from n-1 to n. > Example: CUPS 2.x has boolean option foo, which is changed in CUPS 3.x > to numeric option foobar. In such a case, CUPS3.x model would need to speficy that: - boolean option foo is status deprecated (which means the value can be managed, but the option foo is hidden from the user in the interfaces) - the default value of foobar can be computed from foo value (using compute attribute of Value object. See [1] for gory details) More complex value migration scenarios are possible. All the best [1] http://search.cpan.org/dist/Config-Model/lib/Config/Model/ValueComputer.pm -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Proposal to improve package configuration upgrades
Harald Braumann writes: > I don't really know Config::Model. But the main problem I have with the > current system is, that I only see diffs between the currently > installed version and the new package version. With ucf, you see a diff between current file (i.e. installed version with your modifications) and the new package version. > No what I really would like to see is the diff between the last version > I've merged and the new package version. I fail to see the differences (no pun intented) between "the last version I've merged" and the current file ... > So changes can easily be seen (changes in defaults, new/removed > parameters or just white-space changes?) and merging would work > without a conflict in most cases. With Config::Model: - you would not see white space or any other formatting difference - your customized values would be merged into the new package file (more accurately, loaded in Config::Model configuration tree using the new package *model*). Thus you would see the delta between your new file and the new default value. See this example of a screenshot [1] where the config values different from "default" are shown with a green arrow - yes, merging would work mostly without conflict > Similar to like SCMs work. The main difference between a SCM and Config::Model is that a SCM works purely at text level without knowledge of the semantic of the file under control. OTOH, Config::Model uses the semantic knowledge provided by the model to perform the upgrade. > Config::Model could be useful in addition, but would it support such a > work-flow? Provided I've understood correctly your work-flow, I'd say mostly yes... All the best [1] http://freshmeat.net/screenshots/69123/74589/ -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Proposal to improve package configuration upgrades
Stefano Zacchiroli writes: > Actually, this is something I've been pondering about for a > while. Having /etc under some VCS (as many of us, I presume, already > have by the means of etckeeper and similar tools), diff file merging > can be seriously improved. I tend to disagree. >From a user point of view, you will get the same diff output whether a SCM performs the diff or ucf performs the diff. So your proposal will probably not help my mother-in-law to upgrade the packages on her system ;-) For seasoned sys admin, storing /etc/ files under a SCM will give a much better roll-back capability if a config is screwed up by a manual merge. All the best -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Proposal to improve package configuration upgrades
Manoj Srivastava writes: > Do we have an idea of how many configuration files can be > described in terms of such a model? I do not know how many. I'd say most of the files that do not use variables. For instance exim config is out. I do not know for Apache config files. So far, I've created models for OpenSsh [1] (quite easy) and Xorg [2] (more challenging and the model is still not complete) You will be able to try yourself OpenSsh editor as soon as libconfig-model-openssh-perl is accepted by ftp-masters. > (I generally tend to code configuration files in a scripting > language if the code is written in a scripting language). Uh ? > While I suspect a large number of our configuration files are > simple, I fear that a significan chunk of them are fairly complex; and > possibly not amenable to being described in terms of a non-trivial > model. Agreed. We may need to use hybrid solution for the most complex configuration files. Something like exim-like template + Config::Model for the template variables. All the best [1] http://cpansearch.perl.org/src/DDUMONT/Config-Model-OpenSsh-1.203/lib/Config/Model/models/ [2] http://cpansearch.perl.org/src/DDUMONT/Config-Model-Xorg-0.513/lib/Config/Model/models/ -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Proposal to improve package configuration upgrades
Stefano Zacchiroli writes: > Well, it depends on how dpkg currently handles merges. My impression > (as a user, never looked at the actual code) is that it not even tries > to merge, it simply discovers that the local file is not pristine and > then asks the user. On the contrary, every VCS I'm aware of at least > _tries_ a merge, "succeeding" when changes do not affect the same > patch hunk. Agreed. > Also, there is of course no guaranteed that no conflicting changes > lead to a configuration file semantically sound, That's the main problem I see with VCS like merge. The main problem is that the merge result *should* be reviewed by the user. Will the user always have the skills to spot the places where the merge was wrong ? > but AFAIU you have no guarantee of that with Config::Model > either. They are both about syntax only. No Config::Model is all about checking the *semantic* of a configuration file. So you will have the guarantee that the resulting file is correct from the application point of view. >> >From a user point of view, you will get the same diff output whether a >> SCM performs the diff or ucf performs the diff. >> >> So your proposal will probably not help my mother-in-law to upgrade >> the packages on her system ;-) > > I disagree. It will not help your mother-in-law once she is faced with > the diff, but it will decrease dramatically the number of times she > will be faced with that. ... so maybe we should strive for both? There's may be cases where the merge completes automatically but the end result is wrong. That would be really bad. All the best -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ucf --three-way (was: Proposal to improve package configuration upgrades)
Manoj Srivastava writes: > Well. If the maintainer so desires, ucf does have this to say: > ,[ Manual page ucf(1) ] > | --three-way [ ... ] > Seems like this is what is desired; however, the reason this is > not on by default is that some configuration files can be huge, and ucf > did not want to stash away _all_ the configuration files handled by it > into /var. The exectation was that most developers with smallish > configuration files would use --three-way, but that expectation was > unfounded. I understand. Thanks for the man page snippet. At the risk of drifting away from Config::Model, couldn't ucf propose by default the three-way merge if the configurations files are "smallish" ? (with the option for the maintainer to specify --two-way) By "smallish", I mean below a defined number of lines (say 1000 lines). All the best -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Proposal to improve package configuration upgrades
Manoj Srivastava writes: > /etc/kernel-pkg.conf, for example, is in Perl. You may define > functions, variables, closures (given enough make-kpkg-fu) and have it > all work. Agreed. But this is valid for power user that would not really need the safe merge capability provided by Config::Model. > I dare you to try one for sendmail.cf. (and yes, often don't > use the new fangled m4 stuff) A complete model of sendmail.cf would also be required only for power users like you. For the "mother-in-law use case", it would be more useful to validate that upgrades will work correctly for "Config::Model enabled" packages. Later on, the more packages use Config::Model, the easier will be the system maintenance of "most common" users. All the best -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Proposal to improve package configuration upgrades
Harald Braumann writes: >> I fail to see the differences (no pun intented) between "the last >> version I've merged" and the current file ... > > I mean the last maintainer version I merged into the installed version, > not the result of the last merge. ok > But there are 3 possible situations here: > 1. value has been changed between the last and the new maintainer > version > 2. value was modified locally > 3. both of the above > > In case 1 the modification could be merged silently, in case 2 the > modification should be left alone and in case 3 I'd have to decide what > to do. Config::Model on its own couldn't tell the difference. Currently a maintainer set some value in a package config file to reflect his decisions or debian policy or whatever. With Config::Model such decision would not be encoded in the delivered config file but in the model of the configuration file. This would be specified in the configuration model as a default value. Here's what will happen during an upgrade: a. Config::Model will dump customized value somewhere (dump values which are different from maintainer's model version N. i.e. this will keep track of values from case 2 and 3 *if* they are different from the default value specified in the old model version N ). b. application model is upgraded from N to N+1 (case: 1 and 3: some default config values are changed) c. Config::Model performs the merge: * case 1: no customized value stored in step a. Config::Model will write the default value (specified in the new model version N+1) in the config file * case 2: customized value stored in step a. is loaded, checked and will be written in configuration file * case 3: just like case 2 I hope this replies to your concerns. If not feel free to ask more questions. >> - yes, merging would work mostly without conflict > >> >> > Similar to like SCMs work. >> >> The main difference between a SCM and Config::Model is that a SCM >> works purely at text level without knowledge of the semantic of the >> file under control. OTOH, Config::Model uses the semantic knowledge >> provided by the model to perform the upgrade. > > You could apply the way merges work in an SCM to structured > information. More often than not, the order of the configuration data is not important. For SCM merge, this order *is* important. > Having the diff between the last and the new maintainer version is not > an alternative to Config::Model. The former can tell me what has > changed in what way and the latter can present this information > enriched with its semantic knowledge of the changes. Both are things I > find useful. So my question is, if Config::Model can also deal with the > additional information of what has changed how, so the two things could > be combined? Config::Model can only show the diff between the current state (current file or file + modifications) and the default values from the configuration model. There's no notion of history or diff with previous version of a configuration file. Well, not yet. I'll have to think about this... All the best -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Proposal to improve package configuration upgrades
Stefano Zacchiroli writes: > I can agree, at least in theory. But as we all known, due to how > source code tends to work, in 90% of the cases automatic merges do the > right thing. Well, of course I cannot prove that number, but my > personal feelings is that with a "high confidence" automatic merges do > the right thing. I think your numbers are right. The main problem I see is that the automatic merge will not be able to inform the user whether the merge is correct or not. In case of merge failure, the application will exit on error and leave the average user in the dark. Even 10% of this kinf of failure will be badly perceived. > You know, in the general case it is an undecidable problem, so I > seriously doubt Config::Model can be the silver bullet. It's not as I already know that Config::Model cannot address *all* config files. > Possibly you can get a good coverage of most of the files we have > under /etc which have a trivial structure (hence the questions > raised by other people: how many of those files in a typical > installation you can cover?). Potentially, I'd say 90% of the files (very ballpark figure). But the configuration files need to be created. Config::Model is designed to reduce the work (and maintenance) work as the model are specifed in a data structure. This data structure can be created and maintained with a GUI (Config::Model::Itself). > But then we are back at the issue of a 80-20 problem, and I see the > VCS solution as more flexible and more readily available. Agreed. But VCS solution is a 80% success/20% silent failure. Config::Model is a 80% success/20% abort. The latter should be easier to deal with for average user. > But again, it looks to me that the two approaches can coexist. Absolutely: Something like try Config::Model, if it fails (missing or incomplete model) may be VCS merge with mandatory user interaction or usual ucf question. > ... now it is only the two of us which needs to stop talking and > start proposing patches as needed :-) :-) For this I need a candidate package with a package maintainer willing to experiment the patch I might send... All the best -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Proposal to improve package configuration upgrades
Harald Braumann writes: >> Agreed. But VCS solution is a 80% success/20% silent >> failure. Config::Model is a 80% success/20% abort. The latter should >> be easier to deal with for average user. > > But you don't need to silently merge (and thus silently fail in some > cases). You can still ask the user about confirmation. Agreed. Some user will think before confirming, others will not. All the best -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
A plan to provide some patch to improve package configuration upgrades (was: Proposal to improve package configuration upgrades)
Stefano Zacchiroli writes: > ... now it is only the two of us which needs to stop talking and start > proposing patches as needed :-) ok. Here's the plan: - Identify a "candidate" package to add (as a patch) an upgrade feature based on Config::Model. - Then, I'll patch this source package to use Config::Model during upgrade and test it at home - Then, I'll send the patch for review and comments Now, I need some help to identify the package I'll will work on. This package should have a configuration not too complex and its configuration definition should not move too fast. So this excludes exim, sendmail and xorg. So, do you have a configuration peeve package that fit the criteria above and bothered you during upgrades ? Does anyone want to participate actively to improve upgrade with Config::Model ? (yes, this is a call for help :-) ) All the best -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: A plan to provide some patch to improve package configuration upgrades
Hello Sorry for the silence, I had a few thing to wrap up before going on with this proposal. Dominique Dumont writes: > ok. Here's the plan: > > - Identify a "candidate" package to add (as a patch) an upgrade > feature based on Config::Model. I'm going to use approx as the candidate package. The config file is very simple. Creating a model for it will not be a problem so I'll be able to focus on the problem of making dpkg and Config::Model working smoothly together. In order for people to follow what I am doing, can I create a new Debian wiki page to explain all the steps ? All the best -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Proposal to improve package configuration upgrades
Stefano Zacchiroli writes: > ... now it is only the two of us which needs to stop talking and start > proposing patches as needed :-) Before patches, I've created a page on Debian wiki to better articulate the proposal: http://wiki.debian.org/PackageConfigUpgrade I'll update this page regularly. I'll follow the rough plan mentioned in this page. I'll send patches on this list as soon as I have something ready. All the best -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: debian/copyright verbosity
Manoj Srivastava writes: > Tracking the potentially hundreds of files with © notices that > make up the binary or the libraries is not something I am likely to > do. People looking for that information can inspect the sources, or ask > upstream, directly. Or use fossology HTH -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755430: ITP: prettify -- syntax highlighting of source code snippets in an html page
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, pkg-javascript-de...@lists.alioth.debian.org, debian-p...@lists.debian.org * Package name: prettify Version : 2013.03.04 Upstream Author : mikesam...@gmail.com * URL : https://code.google.com/p/google-code-prettify/ * License : Apache-2.0 Programming Lang: javascript Description : syntax highlighting of source code snippets in an html page A Javascript module and CSS file that allows syntax highlighting of source code snippets in an html page. Features: * Works on HTML pages * Works even if code contains embedded links, line numbers, etc. * Simple API : include some JS&CSS and add an onload handler. * Customizable styles via CSS. See the themes gallery * Supports all C-like, Bash-like, and XML-like languages. * Extensible language handlers for other languages. * Widely used with good cross-browser support. This lib is a dependency of libmojolicious-perl and will be hosted by pkg-javascript-team -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1691153.FScoRAugts@ylum
Bug#756746: ITP: libtk-objeditor-perl -- A Perl/Tk widget to edit recursively a data structure
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libtk-objeditor-perl Version : 2.008 Upstream Author : Dominique Dumont * URL : https://metacpan.org/release/Tk-ObjEditor * License : Artistic or GPL-1+ Programming Lang: Perl Description : A Perl/Tk widget to edit recursively a data structure Tk::ObjEdtor module provide a widget to edit the content of a Perl data structure. The widget enables recursive edition of deep data structure. ObjEditor is located within a DialogBox widget. I.e. it will appear in its own toplevel window when you invoke the Show() method like the FileDialog widget. -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1683564.dr1IZA8Gal@ylum
Bug#763998: ITP: libopengl-image-perl -- Image loader for OpenGL
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libopengl-image-perl Version : 1.03 Upstream Author : Bob "grafman" Free - graf...@graphcomp.com * URL : https://metacpan.org/release/OpenGL-Image * License : Artistic or GPL-1+ Programming Lang: Perl Description : Image loader for OpenGL This module provides methods to load/modify/save images for use with OpenGL textures, FBOs and VBOs. It also requires at least one supported OpenGL::Image imaging engine. At this time, the following drivers are supported: * Targa - Pure Perl - uncompressed RGBA files (comes with OpenGL::Image). * Magick - Requires PerlMagick (v6.3.5 or newer for best performance). -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1635759.3AZX9dGUL6@ylum
Re: debconf as a registry
On Thursday 16 October 2014 22:34:15 Bas Wijnen wrote: > Oh yes, and I have some code ready for feedback. I haven't written the > script libraries yet (and I want others to write some of them), but I > have written the debhelper module for using them. For what it's worth, lcdproc package [1] uses cme (aka Config::Model) to merge configuration file and upstream changes. On the other hand, debconf is not involved because lcdproc does not need to store a debconf value. cme can be adapted to use a debconf value as some kind of default values (probably a "preset" value in Config::Model terminology) This may provide a way to solve your problem while minimizing the amount of duplicated code between packages. Hope this helps [1] http://anonscm.debian.org/cgit/collab-maint/lcdproc.git/ -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/7002167.9PG9X8XXPj@ylum
Re: so long and thanks for all the fish
On Friday 07 November 2014 17:04:10 Joey Hess wrote: > It's become abundantly clear that this is no longer the project I > originally joined in 1996. We've made some good things, and I wish > everyone well, but I'm out. I'm very sorry to read this. We'll miss you. All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2367121.aOZJeVcjqt@ylum
Re: debconf and perl : how to use it ?
On Wednesday 04 April 2012 17:01:25 laurent COOPER wrote: > what did I miss ? I've tried to google the Debconf::Client::ConfModule, > I've tried to read the sources, but I didn't find the answer. Any help > would be appreciated. At the risk of beating a dead horse, you may have missed the debconf-devel man page. This page provides an overview of the debconf system for developers. HTH -- https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/-o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201204051017.48886@debian.org
Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)
Le Wednesday 28 March 2012 07:31:19, Jean-Christophe Dubacq a écrit : > > The best way to become "hyper-efficient" is to avoid this kind of > > overhead, automate everything, and be prepared to fail quickly and > > iterate. > > What about a dev. script that would be run in debian/ and would parse > debian/control and send the ITP? I can write that! YOu can start from the script used by debian-perl team: http://anonscm.debian.org/gitweb/?p=pkg-perl/scripts.git;a=blob;f=examples/gen-itp;hb=HEAD This script is somewhat hardwired for pkg-perl team. I hope you can make it more general purpose. Hope this helps Dominique signature.asc Description: This is a digitally signed message part.
Bug#668917: ITP: libio-lcdproc-perl -- Perl extension to connect to a LCD display through lcdproc
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org,jcmul...@gmail.com * Package name: libio-lcdproc-perl Version : 0.037 Upstream Author : Juan C. Muller * URL : http://search.cpan.org/dist/IO-LCDproc/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl extension to connect to a LCD display through lcdproc Lcdproc is a client/server suite including drivers for all kinds of nifty LCD displays. IO::LCDproc module provides a Perl interface to lcdproc. Dominique signature.asc Description: This is a digitally signed message part.
Bug#671209: ITP: libmoosex-role-timer-perl -- Role for measuring elapsed time with Time::HiRes
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org, m...@cpan.org * Package name: libmoosex-role-timer-perl Version : 0.03 Upstream Author : Michael Langner (m...@cpan.org) * URL : http://search.cpan.org/dist/MooseX-Role-Timer/ * License : GPL-1+ or Artistic Programming Lang: Perl Description : Role for measuring elapsed time with Time::HiRes MooseX::Role::Timer is a Moose role that provides timers to your object, making it easier to keep track of how long whatever actions take. Time is measured with Time::Hires so sub-second timers are possible. This Perl module is patched to be compatible with Any::Moose. Dominique signature.asc Description: This is a digitally signed message part.
How often is any package tested for FTBS on main arch ?
Hello We, sdl maintainers, made a recent change in our package by removing unnecessary build depends on -dev packages [1]. Unfortunately, some package did rely on this "extra" dependencies and went ftbs [2]. Now is the question of possible impact (FTBS) on all packages build-depending on sdl package (about 400 of them). Hence the question, how often is a given package rebuilt as part of the FTBS tests ? In other words, knowing that new libsdl1.2-dev package was uploaded on April 10, can we be confident that all potential ftbs were detected ? Given that freeze time in quite close, we are considering to put back the extra build dependencies if too many packages are impacted. We'd then clean up after Wheeze release. All the best [1] http://packages.debian.org/changelogs/pool/main/libs/libsdl1.2/libsdl1.2_1.2.15-3/changelog [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669571 For the record, these ftbs are now all fixed -- https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/-o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201205041008.44819@debian.org
Re: How often is any package tested for FTBS on main arch ?
Le Friday 4 May 2012 11:09:52, Neil Williams a écrit : > Dominique Dumont wrote: > > We, sdl maintainers, made a recent change in our package by removing > > unnecessary build depends on -dev packages [1]. > > ... at which point you should have looked at the list of reverse > dependencies and done some tests yourselves before uploading ... > > i.e. not rebuild all 400 necessarily but to identify those which of > those 400 do not already build-depend on the packages you removed and at > least let the maintainers of the packages know that your change may > reveal an RC bug in their packages. Sorry, no. SDL team was recenty reconstructed from scratch [1] and we have only 2 active people. I don't count myself as active in sdl team as I mostly do package reviews and upload. We just don't have the time to perform what you suggest just to compensate for easy-to-fix packaging mistakes. > > Unfortunately, some package did rely on this "extra" dependencies and > > went ftbs [2]. > > ... which could, arguably, be jointly your fault as this could have > been handled cleanly if done so in advance. Not my fault, nor current team's fault: this mistake was done years ago. We are still cleaning up what we found. > Yes, the maintainer of the > other packages made a mistake by relying on indirect dependencies (it's > usually best to build-depend on everything you check for in your > configure stage) but that bug was revealed by your change, so it would > have been helpful to raise this as a problem in advance. Agreed. I admit I did not foresee the potential problem. > How about doing the real work instead and identifying which packages > might be affected, alerting those maintainers and starting a few > rebuild tests of this shortened list? Then you've got some real data > to make the decision about what to do. Actually, the whole point of my mail was to gather real data from work already done. Thanks to Lucas, we know about failing packages. Too bad we don't know about succeeding packages. All the best [1] http://ddumont.wordpress.com/2011/11/19/sdl-team-revival/ Dominique signature.asc Description: This is a digitally signed message part.
Re: How often is any package tested for FTBS on main arch ?
Le Saturday 5 May 2012 12:29:03, Neil Williams a écrit : > That would have been fine but the upload had been made without this > check being done. This could have been so much better if the discussion > had preceded the upload. ok. there's a misunderstanding. I do not want to justify the upload that was done without prior communication: This was a mistake. Mistakes happens. If a similar situation occurs, proper communication will be done before upload. All the best Dominique signature.asc Description: This is a digitally signed message part.
