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
On Wed, Nov 27, 2013 at 11:39:50AM -0400, Joey Hess wrote:
> Bas Wijnen wrote:
> > Debconf actively overwriting values is slightly different from it giving
> > you a wrong default which it then allows you to set to the desired value
> > again. The former is overwriting, the latter is just very ann
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
Bas Wijnen wrote:
> Debconf actively overwriting values is slightly different from it giving
> you a wrong default which it then allows you to set to the desired value
> again. The former is overwriting, the latter is just very annoying.
>
> Then again, with debconf's priority scheme, it may well
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
35 matches
Mail list logo
