Hi,
Continuing my sweep of currently open topics, I have been
looking at the open reports in the BTS. I have tried to come up with
opinions on the status and actions required. Since this is a long
list, I've just started at the top, and am working my way down. Any
comments or correctio
Your message dated Tue, 29 Aug 2000 23:24:28 -0500 (CDT)
with message-id <[EMAIL PROTECTED]>
and subject line #61058: FHS: /usr/local/share/man instead of /usr/local/man ?
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If th
Hi,
man-db 2.3.17-1 now does the right thing, and the FHS folks
have agreed to incorporate that in the next revision of the FHS. I do
not think we need make policy on this. I am thus closing this, since
this issue has been satisfactorily resolved.
manoj
--
Smoking is one of t
On Tue, Aug 29, 2000 at 02:57:30PM -0500, Manoj Srivastava wrote:
> 6.3. Details of unpack phase of installation or upgrade
> 6.4. Details of configuration
> 6.5. Details of removal and/or configuration purging
These sections surely have some technical details that the Policy doesn't
need to conta
>>"Myth" == Franklin Belew <[EMAIL PROTECTED]> writes:
Myth> On Tue, Aug 29, 2000 at 02:57:30PM -0500, Manoj Srivastava wrote:
>> lots of neat stuff>
Myth> Can we add a section on shared objects that are merely plugins
Myth> or components of a larger program? For example: xmms plugins,
Myth
On Tue, Aug 29, 2000 at 02:57:30PM -0500, Manoj Srivastava wrote:
Can we add a section on shared objects that are merely plugins or components
of a larger program?
For example: xmms plugins, and mozilla xpcom objects
Frank aka Myth
Hi,
I went through the packaging manual, and these are the parts I
think belong in policy (I had the full text for these sections in
this message, but I was afraid it would pass the max message size
limit). I am also ambivalent about sections like 4.1 "Syntax of
control files". That se
On Tue, 29 Aug 2000 10:57:43 +0200
Roland Rosenfeld <[EMAIL PROTECTED]> wrote:
> On Mon, 28 Aug 2000, Matt Kraai wrote:
> BTW: Can someone explain me, why a mailbox should has to be group
> mail writable? Are there any MDAs, which don't run with root
> permission? With procmail installed, I ca
Previously Manoj Srivastava wrote:
> I think the tie has come for us to reexamine the packaging
> manual, and extract the things that ought to be policy, and let the
> other bits go to the dpkg maintianers for update.
Very much agreed!
Wichert.
--
_
On Tue, Aug 29, 2000 at 10:57:43AM +0200, Roland Rosenfeld wrote:
> BTW: Can someone explain me, why a mailbox should has to be group mail
> writable?
I think it's just an artifact, just like the sentence saying the spool
directory should be mail.mail, when we haven't been using that in ages.
On Mon, 28 Aug 2000, Matt Kraai wrote:
> Policy 3.2.1.0 states that MUAs should be setgid mail. This is so that
> they can create lockfiles in /var/spool/mail. This has the unfortunate
> consequence that MUA bugs can be exploited to read the email of other
> users. A setgid mail locking utility
>>"Joey" == Joey Hess <[EMAIL PROTECTED]> writes:
Joey> Well that wording has been there forever, so this cannot be a recent
Joey> change in policy, though it could be a change in the way some people
Joey> interpret policy.
My impression has always been that the packaging manual was
p
>>"Christian" == Christian Hammers <[EMAIL PROTECTED]> writes:
Christian> ... to be replaced by what? The maintainers simply won't
Christian> write manpages en mass, so when deleting undocumented(1)
Christian> many packages will have binaries without manpage making it
Christian> harder for new
>>"Matt" == Matt Kraai <[EMAIL PROTECTED]> writes:
Matt> Howdy, Policy 3.2.1.0 states that MUAs should be setgid mail.
Matt> This is so that they can create lockfiles in /var/spool/mail.
Matt> This has the unfortunate consequence that MUA bugs can be
Matt> exploited to read the email of other
14 matches
Mail list logo
