-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As I mentioned, the source of your debconf problems was already layed out in detail in different bug reports e.g. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=279030
- --------------------------------- > First: dpkg is asking, not ucf (ucf's questions look a bit different). > Second: (indirectly) *you* are asking (dpkg does it on behalf of > you :)), because you shipped the file as conffile and you > modified it later (in the postinst), but before dpkg's > conffile handling takes place :) > > > Maybe it is a bug, however using "ucf" for manipulating configuration > > file seems to be allowed. This was MY bugs before using ucf, now i think > > it is no more mine. > > ucf is an *alternative* to dpkg's conffile handling, it does work > standalone, not on top of it. > > man ucf says: > This script attempts to provide conffile like handling for > files installed under /etc not shipped in a Debian package, > but handled by the postinst instead. - ------------------ That sounds interesting. You can read it like that: When using ucf, do not provide an /etc/configfile in the debian package but let postinst create one dynamically. It should actually write the file from scratch! I guess it actually writes it to a string or tempfile first and then checks, if there is already a file with that name and acts accorrdingly, asking you wether or not to overwrite. You are actually providing the default file with the package. Then generate a new one and then ufc asks if it should overwrite the file you yust provided. What for do you provide the file in the first place if ucf will create one anyway, even if the user just clicks enter, enter, enter? There is no logic in this! - ------------------------- > > Debian policy states > that files under /etc which are configuration files must pre- > serve user changes, and this applies to files handled by > maintainer scripts as well. - --------------------------------- Reading this right, it says: a conffile is a file that is provided as is by the package and not one that you intend to change in postinst. However, dpkg will check if a file marked as conffile is already existant and warn if true, asking the user for a decision > --------------------------- > > Using ucf, one may ship a bunch > of default configuration files somewhere in /usr ( > /usr/share/<pkg> is a good location), and maintain files in > /etc, - ---------------------- While maintain in this case does actually mean write/create not change!!!! You try to change the file you just shipped with the package. DO NOT DO THAT! Write one from scratch with ucf! - ----------------------- > > preserving user changes and in general offering the > same facilities while upgrading that dpkg normally provides > for "conffiles" - -------------------------- this does not mean, that ucf handles files marked as conffiles!!!! It says: UCF handles its newly generated file with the same care dpkg handles conffiles. With the same care, it DOES NOT handle conffiles!!!! However it will make sure, that it does not overwrite a possibly existant version of the file it intends to create. This may be or will most likely be a configuration file but it is not a "conffile" since it MUST NOT be shiped with the package and therefore CAN NOT be marked as "conffile" in the package. "conffile" IS NOT just any configuration file!!!! You did misunderstand that!!! "conffile" is a file shipped in the package that is marked as "conffile". But you MUST NOT ship a file as "conffile" and then try to overwrite it in postinst, THIS IS A NO-GO! So if you manage your config-file(s) through ucf you must not ship those files as dpkg "conffile"s, because these two methods will collide then (as they do in your case) and you must not ship a file with the same path and name in your package for the same reason. You either provide static "conffile"s or you generate dynamic configuration files with ucf. I know I am repeating myself, but it seems necesary. - ------------------------------------ > > /usr/share/doc/ucf/examples/postinst shows two different ways to > deal with ucf config-files: > * a simple static approach where the maintainer ships his master > version as normal package file at another location (in the example > this is /usr/share/foo/configuration) and > * a dynamic approach (which is what you are doing and which is why > most maintainers will use ucf at all) where the master version is > created on-the-fly as a temp-file. > > But shipping the config-file as dpkg-conffile on the one hand and > creating it dynamically as ucf-configfile on the other hand leads > to collisions like in your case. - --------------------------------- As I understand this, you should either go with ucf or with dpkg-conffile. You are actually usind dpkg to ask the questions and intend to generate a config file dynamically but also providing a default config file as dpkg conffile, which of course results in a colission of the two config file sources. Thats why this annoying overwriting question appears. Your answer, by the way: - --------------------------------- > Hummm... I see my error, you think that if i stop providing > /etc/default/mldonkey-server, i could handle it through ucf ? - --------------------------------- Well, what are you waiting for? Later comment, same conclusion: - --------------------------------- > Yes, I think this would be the best solution in your case, > because you try to handle configuration things via debconf > and thus you search a way to modify the config-file on the > fly. > > The other way would be to throw all the debconf stuff away > and just provide a static default conffile (dpkg conffile, > no ucf at all - perhaps the version you ship along with the > package currently) and let users do their changes manually. > > But... whatever you decide to do - you should try to keep > things in a clean state. I.e. if you decide to no longer use > ucf but dpkg's conffile, make sure, the config file gets > removed from ucf's sphere of responsibility (I'm not sure, > if ucf --purge removes the file itself too, which could > not be what you want :)). > The same applies in the other direction too: if you decide > to use ucf, make sure, dpkg doesn't feel responsible anymore > (which is not so easy too, because conffiles are handled > specifically - they are not removed for example just because > the package doesn't contain them anymore). > > > I am not sure i will try, even if what you told me is really useful. I > > think i will ask less question, because a lot of values in this file are > > not really interesting, and generally are too technical. > > Well, because of this debconf invented priorities. > Have a look at snort for example: > db_beginblock > db_input medium snort/interface || true > db_input high snort/address_range || true > db_input low snort/disable_promiscuous || true > db_endblock > db_go > Depending on how users configured their debconf (debconf/priority), > they will only be asked questions with equal or higher priorities. > I.e. a user like me who configured debconf/priority to low will > see all questions, while a normal user who left debconf/priority > at its default (medium) will only see the first two questions > while the third is not shown to him but gets its default value > instead. No need to mention that you have to provide meaningful > defaults then :) > > > regards > Mario - --------------------------------- My conclusion: Either go a pure dpkg or a pure ucf way. I do not know insights about any of these ways, but it seems to me, according to the comments above that you are not only shipping a file and trying to dynamically generate one but actually asking questions with dpkg while they should be asked with ucf in your case, which might be the reason, why no matter what answer I choose on the overwrite question, my actual debconf decisions never ever make it into the config file!!!!!! NEVER EVER, neither way!!!!!! Markus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCOouB474Mdsi2dOQRAtn1AKCYGLk20wmd8I7X8I0ydcaXx5teoACeOHEq TwKzr6qUrumiABuc7U4xG8U= =nQN5 -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
