Bug#206684: debian-policy: Proposal for going ahead with mandatory debconf use for prompting

[Steve Langasek]

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 have to.

Agreed.

> 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
> prompting if debconf is not available.

> Or do we want to go a step farther and say that they can unconditionally
> use non-debconf prompting?

Both of these seem fine to me.  I suppose debconf availability should be
determined by whether /usr/share/debconf/confmodule can be sourced
successfully?  Are the debconf maintainers ok with that particular check as
a guarantee?

On Thu, Jul 05, 2007 at 03:58:28PM -0700, Russ Allbery wrote:
> 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
> > prompting if debconf is not available.

> Except, of course, libc6 isn't essential.  Hm.  Maybe just "essential
> packages or packages depended on by essential packages," only worded
> better.

 As an exception, to avoid pre-dependency loops essential packages and their
 pre-dependencies may fall back on non-debconf prompting if debconf is not
 available.

?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#206684: debian-policy: Proposal for going ahead with mandatory debconf use for prompting

[Russ Allbery]

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
> prompting if debconf is not available.

Except, of course, libc6 isn't essential.  Hm.  Maybe just "essential
packages or packages depended on by essential packages," only worded
better.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#206684: debian-policy: Proposal for going ahead with mandatory debconf use for prompting

[Russ Allbery]

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 libc6 depending on debconf is
> significant -- debconf-english, debconf-i18n, liblocale-gettext-perl,
> libtext-iconv-perl, libtext-wrapi18n-perl, libtext-charwidth-perl would
> all have to be usable when unpacked but not configured, AFAICS, in order
> for debconf to be guaranteed-usable in unpacked-only state, and given
> that glibc needs to interact with the user in the preinst in some cases,
> this would become a case of circular pre-depends among essential
> packages.  (libc6 pre-depends on debconf for preinst use; debconf
> pre-depends on debconf-i18n | debconf-english to ensure usability when
> unpacked only, by enforcing unpack ordering; several of the other
> modules depend on libc6.)

> 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 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
prompting if debconf is not available.

Or do we want to go a step farther and say that they can unconditionally
use non-debconf prompting?

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#206684: debian-policy: Proposal for going ahead with mandatory debconf use for prompting

[Steve Langasek]

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 actually necessary or not.

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 libc6 depending on debconf is significant --
debconf-english, debconf-i18n, liblocale-gettext-perl, libtext-iconv-perl,
libtext-wrapi18n-perl, libtext-charwidth-perl would all have to be usable
when unpacked but not configured, AFAICS, in order for debconf to be
guaranteed-usable in unpacked-only state, and given that glibc needs to
interact with the user in the preinst in some cases, this would become a
case of circular pre-depends among essential packages.  (libc6 pre-depends
on debconf for preinst use; debconf pre-depends on debconf-i18n |
debconf-english to ensure usability when unpacked only, by enforcing unpack
ordering; several of the other modules depend on libc6.)

So yes, I don't see any way around this exception for glibc.  postfix would
have no excuse, though.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#206684: debian-policy: Proposal for going ahead with mandatory debconf use for prompting

[Russ Allbery]

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
> build-dependency of an arch: any package to require interaction with the
> user at install time (no use of /dev/tty, and no debconf questions of
> critical priority) because such packages need to be installable
> noninteractively on the buildds.  For other cases, I'm not sure I have
> an opinion on how the conflict should be resolved.

Well, taking off my Policy delegate hat and putting on my Debian user hat,
I do have a strong preference for requiring non-interactive installs to
work.  It's permissable, of course, for anything requiring debconf input
to fail if that input isn't available in the form of pre-seeding, but only
if the input is really required in order to do anything sane, and
pre-seeding should always be supported in that case.  But for everything
else, I don't think maintainer scripts should assume a tty is available.

This is because I care a lot about non-interactive upgrades and
installations.  I want to be able to control package installation with a
configuration management system (Puppet in my case, but Cfengine would
pose the same issues).  We simply run too many Debian systems to be
wasting our time logging on to every system to perform upgrades and
installations, so any package that can't be installed non-interactively is
already buggy and nearly unusable from our perspective.

(Not to mention FAI, which of course has similar issues.)

> 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 actually necessary or not.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#206684: debian-policy: Proposal for going ahead with mandatory debconf use for prompting

[Steve Langasek]

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 isn't mentioned in the policy upgrading-checklist?

> It's still there:

> 6.3. Controlling terminal for maintainer scripts
> 

>  The maintainer scripts are guaranteed to run with a controlling
>  terminal and can interact with the user.  Because these scripts may be
>  executed with standard output redirected into a pipe for logging
>  purposes, Perl scripts should set unbuffered output by setting `$|=1'
>  so that the output is printed immediately rather than being buffered.

Hah, yes, grepping for 'tty' doesn't match on this.

> This seems to me to somewhat contradict section 3.9.1.

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
build-dependency of an arch: any package to require interaction with the
user at install time (no use of /dev/tty, and no debconf questions of
critical priority) because such packages need to be installable
noninteractively on the buildds.  For other cases, I'm not sure I have an
opinion on how the conflict should be resolved.

> The unbuffered output bit also seems rather randomly placed here.

:)

On Wed, Jul 04, 2007 at 11:41:32AM -0700, Russ Allbery wrote:
> > Indeed, there are probably less packages to fix that I thought.

> > Christian, would you be interested in pushing a lenny release goal about
> > this?

> If the release team approves, I would be happy to change the should in
> Policy to must.  Do we need to make any exceptions for essential packages
> like libc6 that may be configured before debconf is available for some
> reason?

Yes, libc6(\.1)* does include such non-debconf prompting code for this
reason, so I think the exception is needed.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#206684: debian-policy: Proposal for going ahead with mandatory debconf use for prompting

[Russ Allbery]

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 upgrading-checklist?

It's still there:

6.3. Controlling terminal for maintainer scripts


 The maintainer scripts are guaranteed to run with a controlling
 terminal and can interact with the user.  Because these scripts may be
 executed with standard output redirected into a pipe for logging
 purposes, Perl scripts should set unbuffered output by setting `$|=1'
 so that the output is printed immediately rather than being buffered.

This seems to me to somewhat contradict section 3.9.1.  The unbuffered
output bit also seems rather randomly placed here.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#206684: debian-policy: Proposal for going ahead with mandatory debconf use for prompting

[Steve Langasek]

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 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 do that through debconf, so it would not
> > > > result in more than 50 or 100 bugs (and that's the worst case scenario).

> > > Hmmm, that many?

> > > [..]

> > > I'm still puzzled by the number of package you announce, Lucas.

> > 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 to be less well maintained, so
> >   changes are higher that they do bad stuff with /dev/tty

> > - I use a workaround (make /dev/tty a copy of /dev/null) so that most
> >   packages reading /dev/tty don't block during the test

> > I'll try to give a better estimation soon.

> Indeed, there are probably less packages to fix that I thought.

> Christian, would you be interested in pushing a lenny release goal about
> this?

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 upgrading-checklist?

Given that this has changed, I don't personally have any objections to this
proposal (and my tentative objection only had to do with the possible
methodology of fiddling with /dev/tty).

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#206684: debian-policy: Proposal for going ahead with mandatory debconf use for prompting

[Russ Allbery]

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 to be less well maintained, so
>>   changes are higher that they do bad stuff with /dev/tty
>> 
>> - I use a workaround (make /dev/tty a copy of /dev/null) so that most
>>   packages reading /dev/tty don't block during the test
>> 
>> I'll try to give a better estimation soon.

> Indeed, there are probably less packages to fix that I thought.

> Christian, would you be interested in pushing a lenny release goal about
> this?

If the release team approves, I would be happy to change the should in
Policy to must.  Do we need to make any exceptions for essential packages
like libc6 that may be configured before debconf is available for some
reason?

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#206684: debian-policy: Proposal for going ahead with mandatory debconf use for prompting

[Lucas Nussbaum]

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 piuparts.
> > > 
> > > Looking at my piuparts results (testing packages in etch), most packages
> > > that prompt the user already do that through debconf, so it would not
> > > result in more than 50 or 100 bugs (and that's the worst case scenario).
> > 
> > Hmmm, that many?
> > 
> > [..]
> > 
> > I'm still puzzled by the number of package you announce, Lucas.
> 
> 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 to be less well maintained, so
>   changes are higher that they do bad stuff with /dev/tty
> 
> - I use a workaround (make /dev/tty a copy of /dev/null) so that most
>   packages reading /dev/tty don't block during the test
> 
> I'll try to give a better estimation soon.

Indeed, there are probably less packages to fix that I thought.

Christian, would you be interested in pushing a lenny release goal about
this?
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Bug#206684: debian-policy: Proposal for going ahead with mandatory debconf use for prompting

[Lucas Nussbaum]

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 packages in etch), most packages
> > that prompt the user already do that through debconf, so it would not
> > result in more than 50 or 100 bugs (and that's the worst case scenario).
> 
> Hmmm, that many?
> 
> [..]
> 
> I'm still puzzled by the number of package you announce, Lucas.

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 to be less well maintained, so
  changes are higher that they do bad stuff with /dev/tty

- I use a workaround (make /dev/tty a copy of /dev/null) so that most
  packages reading /dev/tty don't block during the test

I'll try to give a better estimation soon.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Bug#206684: debian-policy: Proposal for going ahead with mandatory debconf use for prompting

[Christian Perrier]

> 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 do that through debconf, so it would not
> result in more than 50 or 100 bugs (and that's the worst case scenario).


Hmmm, that many?

That's already quite a lot but that seems feasible as long as provided
patches do provide *good quality* debconf prompts:

- correct English
- using the recommended writign style (see DevRefwhich we will
probably enhance during the etch->leny release cycle, as I intend to
work on the wording of debconf templates for all packages that already
use debconf
- and, of course, translation from the beginning if possible

I'm still puzzled by the number of package you announce, Lucas.





signature.asc
Description: Digital signature

Bug#206684: debian-policy: Proposal for going ahead with mandatory debconf use for prompting

[Bill Allombert]

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 (testing packages in etch), most packages
> that prompt the user already do that through debconf, so it would not
> result in more than 50 or 100 bugs (and that's the worst case scenario).

We might need an exception for essential packages (e.g. glibc). Unless
they have to provide both a debconf and a tty interface.
 
Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large blue swirl here. 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#206684: debian-policy: Proposal for going ahead with mandatory debconf use for prompting

[Lucas Nussbaum]

[ 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"
> 
> This won't be happening for sarge. If you want it to happen, please focus
> your efforts on finding packages that don't do it, and supplying patches
> to add the features instead.

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 (testing packages in etch), most packages
that prompt the user already do that through debconf, so it would not
result in more than 50 or 100 bugs (and that's the worst case scenario).
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Bug#206684: debian-policy: Proposal for going ahead with mandatory debconf use for prompting

[Christian Perrier]

(l10n-french removed from the CC listI did not intend to keep this
discussion thereit still belongs to i18n, imho...)


> I'd like to add one thing to the proposal: there needs to be an
> exemption somehow for packages with high priority, e.g. Essential
> packages and those in the dependency chain of debconf itself. Such
> packages must be allowed to use debconf only if available, and otherwise
> fall back to other means of prompting the user.

Sure, this has to be mentioned. 

Let's try to reformulate. We have enough time as this should wait
sarge release.. :-)

Package maintainer scripts may prompt the user if necessary.
Prompting must be accomplished by communicating through a program
which conforms to the Debian Configuration management
specification, version 2 or higher, such as `debconf'[2]. This
program should include a mechanism based on gettext for an easy 
management of user prompting internationalisation.

Packages with "Essential" priority as well as packages debconf
depends upon are exempted from this obligation though they should
use a gettext-based system for allowing user prompting
internationalisation.

Please feel free to rewrite for better english, of course...




  

Bug#206684: debian-policy: Proposal for going ahead with mandatory debconf use for prompting

[Christian Perrier]

Quoting Anthony Towns (aj@azure.humbug.org.au):
> 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"
> 
> This won't be happening for sarge. If you want it to happen, please focus

As I wrote in the bug report, this was not intended to happen for
sarge... I've read your "bits from RM" mailand I'm realistic.. :-)

This BR is here just for the record and for starting a discussion
about this stuff...

> your efforts on finding packages that don't do it, and supplying patches
> to add the features instead.

Well, have a look at the BTS, searching for reports from
[EMAIL PROTECTED] think you'll find something.. :-)

Bug#206684: debian-policy: Proposal for going ahead with mandatory debconf use for prompting

[Colin Watson]

On Fri, Aug 22, 2003 at 07:17:57PM +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"
> 
> This won't be happening for sarge. If you want it to happen, please focus
> your efforts on finding packages that don't do it, and supplying patches
> to add the features instead.

In fairness, he did say that:

> > Of course, this *has* to wait after sarge release. It wouldn't be
> > realistic to include this in the Debian Policy version which will be
> > used for sarge.

I'd like to add one thing to the proposal: there needs to be an
exemption somehow for packages with high priority, e.g. Essential
packages and those in the dependency chain of debconf itself. Such
packages must be allowed to use debconf only if available, and otherwise
fall back to other means of prompting the user.

-- 
Colin Watson  [EMAIL PROTECTED]

Bug#206684: debian-policy: Proposal for going ahead with mandatory debconf use for prompting

[Anthony Towns]

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"

This won't be happening for sarge. If you want it to happen, please focus
your efforts on finding packages that don't do it, and supplying patches
to add the features instead.

Cheers,
/\_
aj   <-- wearing Release Manager hat

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   ``Is this some kind of psych test?
  Am I getting paid for this?''


pgplfCJPMYIN3.pgp
Description: PGP signature

Bug#206684: debian-policy: Proposal for going ahead with mandatory debconf use for prompting

[Christian Perrier]

Package: debian-policy
Version: 3.6.1
Severity: wishlist

Now that debconf use is recommended in Policy (since 3.6.1), I think it's
time to think about the future. 

During the discussion about this amendment (bug #176506), it was decided to
only make this a "should" requirement, which is achieved now.

This proposal is what I think to be the next step : make this a "must"

I added something about the mandatory use of a gettext-based system for user
prompts. Basically, this means that our Holy Policy would require the use of
"po-debconf" for debconf..:-)

I propose that the first paragraph of 3.10.1 is to be rewritten to :

 Package maintainer scripts may prompt the user if necessary.
 Prompting must be accomplished by communicating through a program 
 which conforms to the Debian Configuration management specification, 
 version 2 or higher, such as `debconf'[2]. This program should allow
 easy translation by using a system based on gettext files for storing
 the texts of questions and their translations.

Of course, this *has* to wait after sarge release. It wouldn't be realistic to
include this in the Debian Policy version which will be used for sarge.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux mykerinos 2.4.21 #1 jeu jui 24 08:36:17 CEST 2003 i686
Locale: LANG=fr_FR.ISO-8859-1, LC_CTYPE=fr_FR.ISO-8859-1 (ignored: LC_ALL set 
to fr_FR)

-- no debconf information