|
Home > Archive > Debian Developers > April 2004 > rmail, m-t-a, and uucp
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
rmail, m-t-a, and uucp
|
|
| Peter Palfrader 2004-03-25, 3:34 am |
| UUCP uses rmail to inject mail coming in via uucp into the local mail
system. Not so long ago all MTAs provided rmail[1], so (indirectly)
depending on mail-transfer-agent gave uucp the interface it needed.
Now sendmail decided to split off rmail, which of course breaks
sendmail+uucp installations unless the rmail package is installed.
There are two options as I see it right now:
- Require that the MTA provides rmail (either by having their own,
or by depending on rmail).
- Introduce a new virtual package 'rmail' and all packages having an
rmail could declare "Provides: rmail". UUCP could then depend on
rmail rather than a mailer.
Both ways would work for me. There is a 3rd option, but which I really
hate:
- uucp depending on "postfix | exim | exim4-daemon-light | ..... | rmail"
My favorite short term solution is to get sendmail fixed, option 2
requires all MTA packages but sendmail/rmail be changed. What's your
opinion on that.
Peter
1. With the only exception being ssmtp and nullmailer but nobody in their
right mind would install them on a uucp system.
2. #232664
--
PGP signed and encrypted | .''`. ** Debian GNU/Linux **
messages preferred. | : :' : The universal
| `. `' Operating System
http://www.palfrader.org/ | `- http://www.debian.org/
| |
| Lars Wirzenius 2004-03-25, 4:41 am |
| to, 2004-03-25 kello 10:32, Marco d'Itri kirjoitti:
> This would be easy, as a trivial rmail program is a short shell script:
>
> #!/bin/bash
> # This rmail command can be used on postfix and qmail systems without
> # a real rmail binary.
Postfix on my system would seem to contain rmail already, so this is
hopefully unnecessary for Postfix.
--
http://liw.iki.fi/liw/log/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Barth 2004-03-25, 5:37 am |
| * Peter Palfrader (weasel@debian.org) [040325 08:55]:
> My favorite short term solution is to get sendmail fixed, option 2
> requires all MTA packages but sendmail/rmail be changed. What's your
> opinion on that.
I think it's definitly too late in the release process to force all
MTAs to add an additional virtual package. Furthermore, uucp does not
really depend on rmail, because uucp could be used for other things
then mail (e.g. news).
So, for now I'd say uucp should recommend exim4 | rmail | mta, and
drop the last recommendation after release of sarge.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Herbert Xu 2004-03-25, 5:37 am |
| Marco d'Itri <md@linux.it> wrote:
> [-- text/plain, encoding quoted-printable, charset: us-ascii, 19 lines --]
>
> On Mar 25, Peter Palfrader <weasel@debian.org> wrote:
>
>
> This would be easy, as a trivial rmail program is a short shell script:
>
> #!/bin/bash
> # This rmail command can be used on postfix and qmail systems without
> # a real rmail binary.
>
> IFS=" " read -r dummy from dummy
>
> exec /usr/sbin/sendmail -i -f "$from" -- "$*"
If it's so trivial what was the reason that sendmail had to split it
into a separate package?
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adrian Bunk 2004-03-25, 5:38 am |
| On Thu, Mar 25, 2004 at 08:19:39AM +0100, Peter Palfrader wrote:
> UUCP uses rmail to inject mail coming in via uucp into the local mail
> system. Not so long ago all MTAs provided rmail[1], so (indirectly)
> depending on mail-transfer-agent gave uucp the interface it needed.
>
> Now sendmail decided to split off rmail, which of course breaks
> sendmail+uucp installations unless the rmail package is installed.
For the near future:
Reassign #232664 to sendmail.
If something is split off a package, the package has to depend on the
new package until after the next stable release. This is the only way to
prevent breakages on upgrades, (e.g. with the Debian 3.0 uucp package
and the Debian 3.1 sendmail package).
> There are two options as I see it right now:
>...
> - Introduce a new virtual package 'rmail' and all packages having an
> rmail could declare "Provides: rmail". UUCP could then depend on
> rmail rather than a mailer.
>...
This sounds like the best solution.
As a positive side effect, if they all Conflict with each other this
would be better than the fragile conflicts of the rmail package that
breaks with every new MTA that enters Debian.
> Peter
>...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adrian Bunk 2004-03-25, 5:38 am |
| On Thu, Mar 25, 2004 at 10:52:50AM +0100, Andreas Barth wrote:
> * Peter Palfrader (weasel@debian.org) [040325 08:55]:
>
> I think it's definitly too late in the release process to force all
> MTAs to add an additional virtual package.
>...
Why?
There is not even an announced date for the beginning of the freeze and
the changes required for the MTAs are pretty simple.
> Cheers,
> Andi
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Barth 2004-03-25, 5:38 am |
| * Adrian Bunk (bunk@fs.tum.de) [040325 11:25]:
> On Thu, Mar 25, 2004 at 10:52:50AM +0100, Andreas Barth wrote:
[color=darkred]
> Why?
>
> There is not even an announced date for the beginning of the freeze and
> the changes required for the MTAs are pretty simple.
We have already enough RC-grade, simple bugs open, so that I
personally would like to not add more bugs to this list.
Of course, that's just my personal opinion, and I'm not a RM.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Metzler 2004-03-25, 6:34 am |
| Herbert Xu <herbert@gondor.apana.org.au> wrote:
> Marco d'Itri <md@linux.it> wrote:
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
> If it's so trivial what was the reason that sendmail had to split it
> into a separate package?
Sendmail's rmail is smarter and according to the docs does more. It
not only invokes /us/sbin/sendmail with correct options but also
replaces the usual mbox "From foo..." lines with a bang-path.
However the latter is probably only useful for sendmail and sucks for
other MTAs.
http://bugs.debian.org/212532
cu and- ppl should use bsmtp anyway -reas
--
NMUs aren't an insult, they're not an attack, and they're
not something to avoid or be ashamed of.
Anthony Towns in 2004-02 on debian-devel
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2004-03-25, 8:39 am |
| On Mar 25, Peter Palfrader <weasel@debian.org> wrote:
> - Require that the MTA provides rmail (either by having their own,
> or by depending on rmail).
This would be easy, as a trivial rmail program is a short shell script:
#!/bin/bash
# This rmail command can be used on postfix and qmail systems without
# a real rmail binary.
IFS=" " read -r dummy from dummy
exec /usr/sbin/sendmail -i -f "$from" -- "$*"
--
ciao, |
Marco | [5327 sfeMF7BZQ29tM]
| |
| Marco d'Itri 2004-03-25, 8:39 am |
| On Mar 25, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> If it's so trivial what was the reason that sendmail had to split it
> into a separate package?
People using bang paths need a real rmail command, and I suppose that
for large sites there are good reasons for using something more compact
than bash to process each incoming email.
--
ciao, |
Marco | [5333 taddSTa2huaHc]
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adrian Bunk 2004-03-25, 11:35 am |
| On Thu, Mar 25, 2004 at 11:27:36AM +0100, Andreas Barth wrote:
>
> We have already enough RC-grade, simple bugs open, so that I
> personally would like to not add more bugs to this list.
>...
If some simple to fix RC bugs would delay a release in a project with
over 1000 developers, the problem was not in the bugs...
> Cheers,
> Andi
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2004-03-25, 2:34 pm |
| On Thu, Mar 25, 2004 at 11:21:41AM +0100, Adrian Bunk wrote:
> On Thu, Mar 25, 2004 at 10:52:50AM +0100, Andreas Barth wrote:
[color=darkred]
> Why?
> There is not even an announced date for the beginning of the freeze and
> the changes required for the MTAs are pretty simple.
But there's no basis in policy for claiming this is an RC bug in the MTA
currently, so it's not reasonable to demand that that all maintainers of
packages providing mail-transport-agent address this before release, or
to expect the release manager to delay a freeze because of it. (And
given that reducing freeze time is a stated goal of testing, I don't
think the lack of an announced freeze is all that useful in gauging our
time to release.)
If this really constitutes an RC problem for the uucp package (and some
have suggested in this thread that it may not), a defensive strategy
would be for the uucp maintainer to start things moving for an rmail
virtual package, file bugs requesting the relevant packages to add
Provides: rmail, NMU where necessary and feasible, and be prepared to
list a number of package alternatives for sarge.
Regardless, I don't think this bug is sufficient to claim that sendmail
*must* continue to depend on rmail for sarge in order to support partial
upgrades. AFAIK, the only package in the archive which depends on
rmail's functionality is uucp, and it had an incorrect dependency in
woody anyway, because Depends: m-t-a did not guarantee the presence of
rmail then, either.
--
Steve Langasek
postmodern programmer
| |
| Bill Allombert 2004-03-25, 3:34 pm |
| On Thu, Mar 25, 2004 at 12:39:20PM -0600, Steve Langasek wrote:
> Regardless, I don't think this bug is sufficient to claim that sendmail
> *must* continue to depend on rmail for sarge in order to support partial
> upgrades. AFAIK, the only package in the archive which depends on
> rmail's functionality is uucp, and it had an incorrect dependency in
> woody anyway, because Depends: m-t-a did not guarantee the presence of
> rmail then, either.
I would submit that users can rely on functionalities available in a
package without an explicit package dependency.
So if sendmail provided a rmail executable, upgrading to sarge should
not removing it silently.
As far as I know, policy say nothing about the upgrade process between
two releases, but notwithstanding we are commited to provide trouble-free
upgrade between stable releases.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Wouter Verhelst 2004-03-25, 6:35 pm |
| On Thu, Mar 25, 2004 at 09:02:53PM +0100, Bill Allombert wrote:
> On Thu, Mar 25, 2004 at 12:39:20PM -0600, Steve Langasek wrote:
>
> I would submit that users can rely on functionalities available in a
> package without an explicit package dependency.
>
> So if sendmail provided a rmail executable, upgrading to sarge should
> not removing it silently.
I would second that, on the basis that there is precedence in a fairly
high number of other cases, so high a number in fact that it would be
fair to call this "established practice". Try "apt-cache search
transition remove" once.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
| |
| Claus Färber 2004-03-26, 2:38 pm |
| Andreas Barth <aba@not.so.argh.org> schrieb/wrote:
> Furthermore, uucp does not really depend on rmail, because uucp could
> be used for other things then mail (e.g. news).
Sounds like a "Recommends".
Claus
--
http://www.faerber.muc.de
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Peter Palfrader 2004-03-28, 10:34 am |
| On Thu, 25 Mar 2004, Adrian Bunk wrote:
> If something is split off a package, the package has to depend on the
> new package until after the next stable release. This is the only way to
> prevent breakages on upgrades, (e.g. with the Debian 3.0 uucp package
> and the Debian 3.1 sendmail package).
I think this is a good idea. Can we add this to the policy?
Peter
--
PGP signed and encrypted | .''`. ** Debian GNU/Linux **
messages preferred. | : :' : The universal
| `. `' Operating System
http://www.palfrader.org/ | `- http://www.debian.org/
| |
| Andreas Barth 2004-03-28, 11:35 am |
| * Peter Palfrader (weasel@debian.org) [040328 17:40]:
> On Thu, 25 Mar 2004, Adrian Bunk wrote:
[color=darkred]
> I think this is a good idea. Can we add this to the policy?
Yes, I think we should. (And I consider this to be a policy-change
that we can do before release of sarge, w/o breaking too many
packages.)
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bill Allombert 2004-03-28, 4:34 pm |
| On Sun, Mar 28, 2004 at 05:46:38PM +0200, Andreas Barth wrote:
> * Peter Palfrader (weasel@debian.org) [040328 17:40]:
>
>
>
> Yes, I think we should. (And I consider this to be a policy-change
> that we can do before release of sarge, w/o breaking too many
> packages.)
Is it really a policy change ? As far as I know all major packages
splits had followed the above rule, and policy doesn't seem to document
upgrade requirement between stable releases at all.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Branden Robinson 2004-03-29, 3:36 pm |
| On Sun, Mar 28, 2004 at 10:45:54PM +0200, Bill Allombert wrote:
> On Sun, Mar 28, 2004 at 05:46:38PM +0200, Andreas Barth wrote:
>
> Is it really a policy change ? As far as I know all major packages
> splits had followed the above rule, and policy doesn't seem to document
> upgrade requirement between stable releases at all.
It has been said that the Policy Manual is supposed to document existing
practice...
--
G. Branden Robinson | If you have the slightest bit of
Debian GNU/Linux | intellectual integrity you cannot
branden@debian.org | support the government.
http://people.debian.org/~branden/ | -- anonymous
| |
| Adam Heath 2004-03-29, 4:35 pm |
| On Mon, 29 Mar 2004, Branden Robinson wrote:
> On Sun, Mar 28, 2004 at 10:45:54PM +0200, Bill Allombert wrote:
>
> It has been said that the Policy Manual is supposed to document existing
> practice...
Then why does it talk about Enhances?
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Clint Adams 2004-03-29, 4:35 pm |
| > It has been said that the Policy Manual is supposed to document existing
> practice...
There's no need for you to encourage them.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Branden Robinson 2004-03-30, 3:34 am |
| On Mon, Mar 29, 2004 at 02:43:26PM -0600, Adam Heath wrote:
> On Mon, 29 Mar 2004, Branden Robinson wrote:
>
> Then why does it talk about Enhances?
Good question.
--
G. Branden Robinson | Religious bondage shackles and
Debian GNU/Linux | debilitates the mind and unfits it
branden@debian.org | for every noble enterprise.
http://people.debian.org/~branden/ | -- James Madison
| |
| Manoj Srivastava 2004-03-30, 10:35 am |
| On Tue, 30 Mar 2004 03:10:18 -0500, Branden Robinson <branden@debian.org> said:
> On Mon, Mar 29, 2004 at 02:43:26PM -0600, Adam Heath wrote:
Wrong. It has been taken so out of context, and has so much
elided, as to be provocatively deceptive; at least the provocation is
par for the course.
Policy does not document all existing practice. It only
incorporates a minimal ruleset that is required for systems
integration (usually selecting one branch from several equally viable
technical options). It is not a best practices document.
Policy also should almost never (unless directed by the
tech-ctte, and perhaps the DPL) cause a change that would make a
significant chunk of packages instantly buggy; for such changes, we
implement a gradual transition plan, allowing for partial upgrades
(and perhaps using release goals as motivators). Part of the
rationale for this is common sense; a global change, in the past, has
taken time, and having either a large number of RC bugs, or ignoring
a large number of bugs that would otherwise be RC seems silly; and,
anyway, there are concerns that the policy group does not really have
the power to change policy drastically. This is the basis of the
policy shall not be used as a stick to beat developers with.
Nor does it _always_ document only existing practices. What
that misquoted statement was a part of was a larger thesis that is
meant to suggest that policy is not the place for testing out design;
if a complicated technical proposal is to be made into policy, it
should be independently implemented, have all the kinks worked out,
and then have that working model be implemented as policy. Having to
change policy back and forth while a design is being worked out needs
be avoided.
[color=darkred]
Because a) the practice exists, b) any package can use Exists
without breaking anything, and convey information to the user, and c)
it emphasizes what I said above.
[color=darkred]
> Good question.
It merely goes to show either a profound ignorance of what
policy has been about for the last few years, or, a deliberate
attempt to goad me.
manoj
--
One nuclear bomb can ruin your whole day.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2004-03-30, 10:35 am |
| On Thu, 25 Mar 2004 21:02:53 +0100, Bill Allombert <allomber@math.u-bordeaux.fr> said:
> So if sendmail provided a rmail executable, upgrading to sarge
> should not removing it silently.
Contrast this with dpkg, which correctly depends on dselect
after splitting it out -- and is committed to do so until after the
next release.
> As far as I know, policy say nothing about the upgrade process
> between two releases, but notwithstanding we are commited to provide
> trouble-free upgrade between stable releases.
Sounds like silently splitting a package like that is a bug --
in which case, why do we need policy to tell us not to make buggy
packages?
manoj
--
The shortest measurable interval of time is the time between the
moment I put a little extra aside for a sudden emergency and the
arrival of that emergency.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Branden Robinson 2004-03-31, 3:34 am |
| On Tue, Mar 30, 2004 at 08:32:37AM -0600, Manoj Srivastava wrote:
> Policy does not document all existing practice. It only
> incorporates a minimal ruleset that is required for systems
> integration (usually selecting one branch from several equally viable
> technical options). It is not a best practices document.
>
> Policy also should almost never (unless directed by the
> tech-ctte, and perhaps the DPL) cause a change that would make a
> significant chunk of packages instantly buggy; for such changes, we
> implement a gradual transition plan, allowing for partial upgrades
> (and perhaps using release goals as motivators). Part of the
> rationale for this is common sense; a global change, in the past, has
> taken time, and having either a large number of RC bugs, or ignoring
> a large number of bugs that would otherwise be RC seems silly; and,
> anyway, there are concerns that the policy group does not really have
> the power to change policy drastically. This is the basis of the
> policy shall not be used as a stick to beat developers with.
>
> Nor does it _always_ document only existing practices. What
> that misquoted statement was a part of was a larger thesis that is
> meant to suggest that policy is not the place for testing out design;
> if a complicated technical proposal is to be made into policy, it
> should be independently implemented, have all the kinks worked out,
> and then have that working model be implemented as policy. Having to
> change policy back and forth while a design is being worked out needs
> be avoided.
Okay. Maybe the above should be added to the Policy Manual as a
preface.
--
G. Branden Robinson | When dogma enters the brain, all
Debian GNU/Linux | intellectual activity ceases.
branden@debian.org | -- Robert Anton Wilson
http://people.debian.org/~branden/ |
| |
| Adam Heath 2004-03-31, 6:35 pm |
| On Tue, 30 Mar 2004, Manoj Srivastava wrote:
>
> Because a) the practice exists, b) any package can use Exists
> without breaking anything, and convey information to the user, and c)
> it emphasizes what I said above.
And when the dpkg(and other) tools implement enhances in a way that compatible
with existing uses of it, then it will have been policy's fault for suggesting
the use of enhances, without any implementation to point to.
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bastian Blank 2004-04-01, 4:36 am |
| On Wed, Mar 31, 2004 at 05:16:39PM -0600, Adam Heath wrote:
> And when the dpkg(and other) tools implement enhances in a way that compatible
> with existing uses of it, then it will have been policy's fault for suggesting
> the use of enhances, without any implementation to point to.
anna implements and uses Enhances.
Bastian
--
Insufficient facts always invite danger.
-- Spock, "Space Seed", stardate 3141.9
| |
| Adrian Bunk 2004-04-01, 8:34 pm |
| On Tue, Mar 30, 2004 at 08:38:48AM -0600, Manoj Srivastava wrote:
>...
>
> Sounds like silently splitting a package like that is a bug --
> in which case, why do we need policy to tell us not to make buggy
> packages?
In my experience, convincing maintainers that what they are doing is
wrong is _much_ easier when you are able to show them a section in the
policy that tells how to do it right...
> manoj
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|