On 10/18/2014 05:14 AM, Bas Wijnen wrote:
As I wrote previously, this may only happen if we decide to have such a
library as essential, otherwise this forces to use pre-depends, which
isn't good.
IMO using pre-depends is a lot better than adding a package to
essential, but I'd rather avoid
On Fri, 17 Oct 2014, Jonas Smedegaard wrote:
If package is suitable for unstable but not for testing, please upload
to unstable and file severe bugreport to keep it from entering testing.
I thought so too, but learned that this is a bad idea.
Sometimes, you have to update the package in
On 10/19/2014 at 09:19 AM, Thorsten Glaser wrote:
On Fri, 17 Oct 2014, Jonas Smedegaard wrote:
If package is suitable for unstable but not for testing, please
upload to unstable and file severe bugreport to keep it from
entering testing.
I thought so too, but learned that this is a bad
Quoting The Wanderer (2014-10-19 15:24:03)
On 10/19/2014 at 09:19 AM, Thorsten Glaser wrote:
On Fri, 17 Oct 2014, Jonas Smedegaard wrote:
If package is suitable for unstable but not for testing, please
upload to unstable and file severe bugreport to keep it from
entering testing.
I
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
On 10/17/2014 01:41 PM, Bas Wijnen wrote:
Getting random packages from apt-cache rdepends debconf shows:
- several packages that use debconf for questions that are only about
actions that don't need to be (and aren't) stored in config files.
I previously thought that it was the case. Then
Really, really cool analysis and wor, Bas!
Quoting Bas Wijnen (2014-10-17 07:41:21)
It's dh-parseconfig:
http://wijnen.dtdns.net/archive/unstable/{all,source}/dh-parseconfig*
[...]
I don't have a bug tracker yet, but I can upload this to unstable if
people don't complain too much about the
Quoting Thomas Goirand (2014-10-17 09:51:04)
On 10/17/2014 01:41 PM, Bas Wijnen wrote:
I don't have a bug tracker yet, but I can upload this to unstable if
people don't complain too much about the code. ;-) Then the bts can
be used for feature requests (and bugs of course).
Please don't
On 10/17/2014 04:51 PM, Jonas Smedegaard wrote:
Quoting Thomas Goirand (2014-10-17 09:51:04)
On 10/17/2014 01:41 PM, Bas Wijnen wrote:
I don't have a bug tracker yet, but I can upload this to unstable if
people don't complain too much about the code. ;-) Then the bts can
be used for feature
Quoting Thomas Goirand (2014-10-17 17:47:27)
On 10/17/2014 04:51 PM, Jonas Smedegaard wrote:
Quoting Thomas Goirand (2014-10-17 09:51:04)
On 10/17/2014 01:41 PM, Bas Wijnen wrote:
I don't have a bug tracker yet, but I can upload this to unstable
if people don't complain too much about the
On Fri, Oct 17, 2014 at 03:51:04PM +0800, Thomas Goirand wrote:
On 10/17/2014 01:41 PM, Bas Wijnen wrote:
Getting random packages from apt-cache rdepends debconf shows:
- several packages that use debconf for questions that are only about
actions that don't need to be (and aren't)
As I wrote in the blend thread, reading through bug #311188 raised some
new questions for me about this one.
I will start by explaining the original problem again; it seemed to me
that it wasn't understood by everyone. Then I'll add some new thoughts
based on that bug. Finally, I present some
On 10/17/2014 04:34 AM, Bas Wijnen wrote:
So debconf needs to read configuration files, but it doesn't know how to
parse them. So it does the only thing it can: it uses its cache. Which
means that each and every package that uses debconf must make sure that
they read the configuration files
On Fri, Oct 17, 2014 at 12:37 PM, Thomas Goirand wrote:
maintenance of them, like for example moving a directive from one
section to another (when this happens upstream).
Sounds like you want one of these:
Config::Model based config file upgrades:
https://wiki.debian.org/PackageConfigUpgrade
On Fri, Oct 17, 2014 at 12:37:27PM +0800, Thomas Goirand wrote:
On 10/17/2014 04:34 AM, Bas Wijnen wrote:
So debconf needs to read configuration files, but it doesn't know how to
parse them. So it does the only thing it can: it uses its cache. Which
means that each and every package that
, the package uses debconf as registry.
Funnily enough, debconf itself fails this test.
I don't think this is right. Questions might be asked to know not what to
write into some config file, but to determine directly whether the maintainer
script should take some action right now (eg, restarting
On 11/28/2013 09:56 PM, Ian Jackson wrote:
Jakub Wilk writes (Re: debconf as a registry):
I suggest the following test instead:
1) DEBIAN_FRONTEND=noninteractive apt-get install $package
2) rm -rf /var/cache/debconf
3) DEBIAN_PRIORITY=low apt-get install --reinstall $package
If any
Jakub Wilk writes (Re: debconf as a registry):
I suggest the following test instead:
1) DEBIAN_FRONTEND=noninteractive apt-get install $package
2) rm -rf /var/cache/debconf
3) DEBIAN_PRIORITY=low apt-get install --reinstall $package
If any questions are asked in point 3, the package uses
Bas Wijnen wrote:
As I wrote, the only thing you need is to search for any package using a
config script. Searching for db_input path:\.config$ gives for example
cyrus-sasl2 and bind9 on the first page.
No ,any package using a config script does not use debconf in a buggy
fashion. Sheesh. Are
there are some cases that there is no config file, but I would argue
that in those cases there should be one (otherwise debconf is used as a
registry).
This is fairly typical:
# debconf is not a registry; use the current contents of the default display
# manager file to pre-answer the question
Bas Wijnen wrote:
(1)
It's not about overwriting.
(2)
The point is that debconf will use its own
cache for defaults, which means that running dpkg-reconfigure and then
pressing enter on all but the thing you're interested in changing should
not make any changes on those items, but does in
On Wed, Nov 27, 2013 at 07:10:23AM -0400, Joey Hess wrote:
Bas Wijnen wrote:
(1)
It's not about overwriting.
(2)
The point is that debconf will use its own
cache for defaults, which means that running dpkg-reconfigure and then
pressing enter on all but the thing you're
happen that the
default is used without asking the question, so I suppose there isn't
that much difference.
I still don't understand you, and you are still not providing any
examples, after having made an assertion that a many packages are
misusing debconf as a registry, and pointing to a faulty
On 2013-11-27 16:25, Bas Wijnen wrote:
Ah yes, I hadn't thought of that. But what is required for preseeding
is to provide a database to debconf for one-time use. Since there is a
cache, it can be used for that, but there is no reason that this
provided database has to persist after the
On Wed, Nov 27, 2013 at 05:13:55PM +0100, Andreas Beckmann wrote:
1) manually configure $package using custom values
2) rm -rf /var/cache/debconf
3) DEBIAN_FRONTEND=noninteractive dpkg-reconfigure $package
...
step 1 is the difficult part (someone needs to create custom
preseeding for
packages are
misusing debconf as a registry, and pointing to a faulty code search
which did not seem to find any.
As I wrote, the only thing you need is to search for any package using a
config script. Searching for db_input path:\.config$ gives for example
cyrus-sasl2 and bind9 on the first page
install $package
2) rm -rf /var/cache/debconf
3) DEBIAN_PRIORITY=low apt-get install --reinstall $package
If any questions are asked in point 3, the package uses debconf as registry.
Funnily enough, debconf itself fails this test.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-devel-requ
of sync, most likely
the admin has edited the config file. This means that the value in
there should be used, not the cache of debconf. Packages that use
debconf's cache instead, are rightfully accused of using debconf as a
registry, and should be fixed.
What this means, is that every package
Bas Wijnen wrote:
Currently, many packages only do 2
(Citation needed.)
packages should implement parsing code for it in its config script. My
point is that this results in needless code duplication. Therefore I
would like to move this parsing code to debconf
I'd think it would be obvious
Op 27-11-13 02:44, Joey Hess schreef:
Bas Wijnen wrote:
Currently, many packages only do 2
(Citation needed.)
packages should implement parsing code for it in its config script. My
point is that this results in needless code duplication. Therefore I
would like to move this parsing code
Bas Wijnen wij...@debian.org writes:
What this means, is that every package which asks debconf questions (and
stores the answers in a configuration file) will need to:
1. Parse the configuration file, if it exists, and set the values as
defaults before asking the questions. (in the config
On Tue, Nov 26, 2013 at 09:44:40PM -0400, Joey Hess wrote:
Bas Wijnen wrote:
Currently, many packages only do 2
(Citation needed.)
http://codesearch.debian.net/search?q=db_get+path%3A.*config%24
On Tue, Nov 26, 2013 at 06:16:19PM -0800, Russ Allbery wrote:
Currently, many packages only
Bas Wijnen wij...@debian.org writes:
Certainly. You seem to have misunderstood my intention. I don't mean
to say we should force packages to use a standard package.config. That
file should be used to do all the things it must do. What I'm proposing
is to make it easy for packages with
already installed
from the first 3 pages of results, I found no uses of db_get that didn't
appear to make sense, and none that caused overwriting of values from
system config files.
This is fairly typical:
# debconf is not a registry; use the current contents of the default display
# manager file
If someone would really like to improve the state of debconf use in
config scripts, I think that the best approach would be to find a way
to replace the current imperative config scripts with a declarative
format.
--
see shy jo, fan of applicative functors, though sometimes you gotta
2013/11/27 Joey Hess jo...@debian.org:
I'd think it would be obvious why it's not good design to put parsers
for every possible config file format in debconf.
There is libaugeas.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
36 matches
Mail list logo
