weekly policy summary

1999-08-20 Thread Joey Hess
Here's what's been happening on debian-policy this week (and last week). Note: for details of the policy process, see http://www.debian.org/~srivasta/policy/ch3.html. Also, this summary is available on the web at http://kitenet.net/~joey/policy-weekly.html. Accepted Ame

Bug#42052: PROPOSAL] /var/mail and /var/spool/mail

1999-08-20 Thread Santiago Vila
On Wed, 18 Aug 1999, Joseph Carter wrote: > On Wed, Aug 18, 1999 at 12:56:23PM +0200, Santiago Vila wrote: > > [ Note that I'm not particularly disappointed that someone objects this > > proposal, I think we could well wait for FHS 2.1 to be official before > > going any further ]. > > FHS 2.1 in

Mail locking and NFS caches.

1999-08-20 Thread Thomas Roessler
As far as I know, the current Debian mail locking mechanism is dotlock-based. The message included below (which has been taken from a discussion on #39030) indicates that this mechanism should be augmented to include POSIX locking (fcntl) in order to invalidate any caches. Note that the use of PO

Re: shlibs file changes proposal

1999-08-20 Thread Anthony Towns
On Thu, Aug 19, 1999 at 03:36:29PM -0700, Joel Klecker wrote: > At 19:53 -0700 1999-08-18, Joseph Carter wrote: > >Because even some free programs use shlib plugins without sonames and it'd > >be better to maintain compatibility than to break it simply because we > >would prefer to have sonames? >

Re: What would the tree look like? (was Re: er)

1999-08-20 Thread Anthony Towns
On Wed, Aug 18, 1999 at 11:55:35AM -0700, Joey Hess wrote: > > But in this case, wouldn't it be more useful to have them all available > > everywhere, so that when you're making use of the examples you can get at > > all the data formats at once, without having to have a machine running > > each di

Re: shlibs file changes proposal

1999-08-20 Thread Joseph Carter
On Thu, Aug 19, 1999 at 03:36:29PM -0700, Joel Klecker wrote: > >Because even some free programs use shlib plugins without sonames and it'd > >be better to maintain compatibility than to break it simply because we > >would prefer to have sonames? > > shared objects without sonames are not shared l