In article <[EMAIL PROTECTED]> you write:
>Please provide a rationale. Some of my packages need a static ID (64000
>is assigned, the only one assigned so far) because their spool could
>need to be NFS shared.
As the maintainer of diskless, I am curious:
What packages need a ID that could be share
Processing commands for [EMAIL PROTECTED]:
> severity 41547 normal
Bug#41547: [PROPOSAL] Correct section 3.3 to take account of file-rc
Severity set to `normal'.
> retitle 41547 [ACCEPTED 1/9/99] Correct section 3.3 to take account of file-rc
Bug#41547: [PROPOSAL] Correct section 3.3 to take acco
Hello,
it looks as if we don't have good guidelines what to do about running
daemons when installing packages, or I missed them when glancing at the
policy and packaging manual.
I think it should be specified in the packaging manual when daemons should
be stopped, started, restarted, reloaded et
On Sun, Sep 19, 1999 at 12:45:10AM -0500, Chris Lawrence wrote:
> My point is simply that changing policy does not translate into making
> things happen by fiat. Perhaps you missed the entire point of my
> mail, because it seems like we agree with each other.
Actually... rereading your original p
On Sun, Sep 19, 1999 at 12:45:10AM -0500, Chris Lawrence wrote:
> My point is simply that changing policy does not translate into making
> things happen by fiat. Perhaps you missed the entire point of my
> mail, because it seems like we agree with each other.
*blush* yeah.
--
Raul
On Sun, Sep 19, 1999 at 10:14:09AM -0700, Joseph Carter wrote:
> I have no idea offhand. I just know it's created by inittex and it
> doesn't matter if I tell dpkg to replace mine or not, it will always be
> regenerated by initex.
Uh... initex IIRC generates only .fmt files which should not be co
On Sun, Sep 19, 1999 at 11:59:27AM +0300, Antti-Juhani Kaijanaho wrote:
> > > Should be add `intended for direct user modification'? Are there
> > > configfiles that are `internal' and should be allowed to remain
> > > undocumented?
> >
> > Yes there are some such config files. I believe tetex h
On Sat, Sep 18, 1999 at 06:26:53PM -0700, Joseph Carter wrote:
> > Should be add `intended for direct user modification'? Are there
> > configfiles that are `internal' and should be allowed to remain
> > undocumented?
>
> Yes there are some such config files. I believe tetex has one, for
> examp
On Sep 19, Joseph Carter <[EMAIL PROTECTED]> wrote:
>I think the practice of using static IDs should be deprecated (and
>packages doing it should get lintian warnings..) I disagree with banning
Please provide a rationale. Some of my packages need a static ID (64000
is assigned, the only one assi
On Sat, Sep 18, 1999 at 06:26:53PM -0700, Joseph Carter wrote:
> On Sat, Sep 18, 1999 at 02:32:09PM -0300, Nicolás Lichtmaier wrote:
> > Should be add `intended for direct user modification'? Are there
> > configfiles that are `internal' and should be allowed to remain
> > undocumented?
>
> Yes t
On Sep 19, Raul Miller wrote:
> > On Sep 18, Joseph Carter wrote:
> > > It's a problem if there's no transition to speak of. We apparently have
> > > decided not to make policy that makes a bunch of packages instantly non-
> > > compliant without a reasonable transition.
>
> On Sat, Sep 18, 1999
> On Sep 18, Joseph Carter wrote:
> > It's a problem if there's no transition to speak of. We apparently have
> > decided not to make policy that makes a bunch of packages instantly non-
> > compliant without a reasonable transition.
On Sat, Sep 18, 1999 at 11:24:13PM -0500, Chris Lawrence wrote:
On Sat, Sep 18, 1999 at 01:23:53PM -0700, Seth R Arnold wrote:
> (Actually, if there is any easy way to use the debian package
> management system to find out this info, I suppose that would make me
> more than happy...)
Sadly, there's no ready reference for all the various interfaces
which have e
On Sep 18, Joseph Carter wrote:
> It's a problem if there's no transition to speak of. We apparently have
> decided not to make policy that makes a bunch of packages instantly non-
> compliant without a reasonable transition.
I think we're starting to bastardize the concept of "policy
compliance"
On Sat, Sep 18, 1999 at 09:38:37PM -0400, Michael Stone wrote:
> > I think the practice of using static IDs should be deprecated (and
> > packages doing it should get lintian warnings..) I disagree with banning
> > them outright as it doesn't really give packages a chance to get fixed
> > before t
On Sat, Sep 18, 1999 at 02:32:09PM -0300, Nicolás Lichtmaier wrote:
> Should be add `intended for direct user modification'? Are there
> configfiles that are `internal' and should be allowed to remain
> undocumented?
Yes there are some such config files. I believe tetex has one, for
example.
--
On Sat, Sep 18, 1999 at 06:13:20PM -0700, Joseph Carter wrote:
> I think the practice of using static IDs should be deprecated (and
> packages doing it should get lintian warnings..) I disagree with banning
> them outright as it doesn't really give packages a chance to get fixed
> before they have
Your message dated Sat, 18 Sep 1999 18:03:10 -0700
with message-id <[EMAIL PROTECTED]>
and subject line Weekly policy summary
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibili
On Fri, Sep 17, 1999 at 12:17:59PM -0700, Joey Hess wrote:
> Section 3.2 should not allow static user ids (except root=0) (#43483)
> * Stalled for 2 weeks.
> * Proposed by Andreas Jellinghaus.
> * Policy currently allows for static uid' to be hardcoded into
> daemons. The proposal is to c
On Fri, Sep 17, 1999 at 12:17:59PM -0700, Joey Hess wrote:
> /var/mail and /var/spool/mail (#42052)
> * Old.
> * Proposed by Joseph Carter; seconded by Gordon Matzigkeit, Joey
> Hess and Santiago Vila.
> * This outlines a migration path from /var/spool/mail to /var/mail.
> Old systems
On Fri, Sep 17, 1999 at 02:22:20PM +1000, Anthony Towns wrote:
> That is, that the only consideration about whether a package should be
> added to main, contrib or non-free be its licensing terms.
>
> Packages that are `too buggy to support' or `fail to meet policy
> requirements in a serious way'
> > No I don't think that it's good idea. There's no point adding a bunch of
> > undocumented symlink to all missing man page for configuration file. :-)
> >
> > I agree that having a man page for the configuration file is good but I
> > don't want to force Debian developers to write man page for
22 matches
Mail list logo
