On Thu, Jul 05, 2007 at 03:40:08PM -0700, Russ Allbery wrote:
Steve Langasek [EMAIL PROTECTED] writes:
So yes, I don't see any way around this exception for glibc. postfix
would have no excuse, though.
Okay. From a Policy perspective, I don't really want to single out libc6
unless I
On Wed, Jul 04, 2007 at 12:13:55PM -0700, Russ Allbery wrote:
Last I knew, policy said packages *were* allowed to depend on the
availability of /dev/tty during configuration, even if they're not
supposed to be doing direct prompting by way of it. This seems to have
been changed, but
Steve Langasek [EMAIL PROTECTED] writes:
Well, one of the cases where this has come up in the past is with
programs called /from/ maintainer scripts which need to interact with
the user and are not implemented using debconf.
In practice, it is already prohibited for any package that's a
On Thu, Jul 05, 2007 at 02:26:36PM -0700, Russ Allbery wrote:
Yes, libc6(\.1)* does include such non-debconf prompting code for this
reason, so I think the exception is needed.
Several packages contain such code (including postfix, IIRC). What I was
never sure about was whether it was
Steve Langasek [EMAIL PROTECTED] writes:
To date, I have not been aware of a scenario in which debconf would have
been broken and unusable in the middle of an upgrade as a result of
being unpacked but not yet configured; but the number of packages that
would be rendered virtually-essential by
Russ Allbery [EMAIL PROTECTED] writes:
Okay. From a Policy perspective, I don't really want to single out
libc6 unless I have to. Would it make sense to have a blanket exception
for all Essential packages, something like:
As an exception, essential packages may fall back on non-debconf
On 08/03/07 at 08:02 +0100, Lucas Nussbaum wrote:
On 07/03/07 at 23:07 +0100, Christian Perrier wrote:
I would really like to see that happening at the beginning of the lenny
release cycle. Packages that prompt without using debconf make it
unnecessary difficult to test them using
Lucas Nussbaum [EMAIL PROTECTED] writes:
On 08/03/07 at 08:02 +0100, Lucas Nussbaum wrote:
Well, that's really the worst case scenario. I would have to run
piuparts again to get better numbers, since:
- I'm running piuparts on etch, not sid, and packages
in-sid-but-not-in-etch are likely
On Wed, Jul 04, 2007 at 08:27:40PM +0200, Lucas Nussbaum wrote:
On 08/03/07 at 08:02 +0100, Lucas Nussbaum wrote:
On 07/03/07 at 23:07 +0100, Christian Perrier wrote:
I would really like to see that happening at the beginning of the lenny
release cycle. Packages that prompt without
Steve Langasek [EMAIL PROTECTED] writes:
Last I knew, policy said packages *were* allowed to depend on the
availability of /dev/tty during configuration, even if they're not
supposed to be doing direct prompting by way of it. This seems to have
been changed, but isn't mentioned in the policy
[ context: that bug from 2003 discusses the possibility to switch from
should to must for debconf prompting ]
On 22/08/03 at 19:17 +1000, Anthony Towns wrote:
On Fri, Aug 22, 2003 at 07:46:56AM +0200, Christian Perrier wrote:
This proposal is what I think to be the next step : make this a must
On Wed, Mar 07, 2007 at 05:34:30PM +0100, Lucas Nussbaum wrote:
Hi,
I would really like to see that happening at the beginning of the lenny
release cycle. Packages that prompt without using debconf make it
unnecessary difficult to test them using piuparts.
Looking at my piuparts results
I would really like to see that happening at the beginning of the lenny
release cycle. Packages that prompt without using debconf make it
unnecessary difficult to test them using piuparts.
Looking at my piuparts results (testing packages in etch), most packages
that prompt the user already
On 07/03/07 at 23:07 +0100, Christian Perrier wrote:
I would really like to see that happening at the beginning of the lenny
release cycle. Packages that prompt without using debconf make it
unnecessary difficult to test them using piuparts.
Looking at my piuparts results (testing
14 matches
Mail list logo
