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 rathe
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 te
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 i
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 test
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
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
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
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
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 th
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. Th
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] use
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
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/PackageConfigUpgrad
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 fil
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 co
* Ian Jackson , 2013-11-28, 13:56:
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 debconf as registr
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_PRIORI
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. A
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 ques
* Andreas Beckmann , 2013-11-27, 17:13:
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 ques
d 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 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. Se
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 eve
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 q
ority scheme, it may well 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 debc
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 yo
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 doe
On Wed, Nov 27, 2013 at 12:38:38AM -0400, Joey Hess wrote:
> Bas Wijnen wrote:
> > > (Citation needed.)
> >
> > http://codesearch.debian.net/search?q=db_get+path%3A.*config%24
>
> If the presence of db_get in a config script was always a bug, then I
> [cw]oud modify debconf to not allow db_get in
2013/11/27 Joey Hess :
> 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 listmas...@l
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
Bas Wijnen wrote:
> > (Citation needed.)
>
> http://codesearch.debian.net/search?q=db_get+path%3A.*config%24
If the presence of db_get in a config script was always a bug, then I
[cw]oud modify debconf to not allow db_get in config scripts.
But, it's not. Randomly reviewing only packages I have
Bas Wijnen 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 simple file forma
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
Bas Wijnen 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 script)
> 2. Upd
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 par
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 obviou
holding the same info. If they are out 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 f
36 matches
Mail list logo
