Branden Robinson <[EMAIL PROTECTED]> writes:
> I guess we should start a discussion as to what we want in the runlevels.
> If there's anything that shouldn't be in at least one of the multi-user
> runlevels, xdm is it. What else?
The existing policy is that runlevels are for users to use to con
Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> writes:
> On Mon, Apr 05, 1999 at 04:08:49PM +0200, Santiago Vila wrote:
> > I'm now looking for seconds for this proposal.
why?
Chris Waters <[EMAIL PROTECTED]> writes:
> Joey Hess <[EMAIL PROTECTED]> writes:
>
> > debian/rules clean is already required to reverse the effects of the build.
>
> In theory, yes. But unless you audit the .diff.gz, it's not
> necessarily obvious if this fails.
In fact there are packages
Branden Robinson <[EMAIL PROTECTED]> writes:
> On Sun, Jan 02, 2000 at 01:39:34PM -0500, Raul Miller wrote:
> > I'm not going to second this proposal.
> >
> > I think that it misses the real issue in favor of a rhetorical position.
>
> I disagree. The rationale for this proposal was twofold:
>
Matthew Vernon <[EMAIL PROTECTED]> writes:
> I still maintain that undocumented(7) serves a useful function (as my
> objection said), but perhaps it should be reworded somewhat; maybe we
> should encourage people to check the BTS and submit a bug report, or
> simply "do submit this as a bug if th
Julian Gilbey <[EMAIL PROTECTED]> writes:
> On Sun, Jan 09, 2000 at 12:50:29AM -0300, Nicolas Lichtmaier wrote:
> > Package: debian-policy
> >
> > This is already standard, but I think it should be into policy because I
> > already saw some programs deviating from this expected behaviour.
> >
>
Nicolás Lichtmaier <[EMAIL PROTECTED]> writes:
> You have a cost in being non-standard, and I don't think it is worth it
> this time. What benefits would give us what you propose?
The cost is greater than /etc/mailname or /etc/papersize ?
Debian long ago decided not to worry about the issue of
Ian Jackson <[EMAIL PROTECTED]> writes:
> This would take the form of a `Known-Problems' field in the .changes
> file. Initially this would be an X-C-Known-Problems so that old
> versions of dpkg-dev can build packages; the archive script would
> understand both. The syntax would be something l
> > I don't think so - indeed policy says that packages shouldn't depend
> > on environment variables for their correct behaviour(3.9). I don't
> > disagree that http_proxy as an environment variable is common
> > practice, but I do disagree strongly that this should be made policy -
> > you'd hav
Wichert Akkerman <[EMAIL PROTECTED]> writes:
> I really don't see the use.. if I follow your logic then /usr/lib should
> be just libraries. Okay, but now I have a program that uses a couple
> of bitmaps in its userinterface.. lets make /usr/libbitmap then!
Actually it's /usr/include/X11/bitmap
Please stick to the merits of the proposal and don't speculate about my
motivations. My only intent here is to avoid stamping a faulty design with the
debian seal of approval by putting it in our policy.
Having options that are only available from environment variables and not from
configuration
This is an old thread that I have a new twist on. I just got bit by a purge
that removed a file I really wouldn't have liked it to, but I think the
packages involved were doing what they should have been doing according to
current policy. I think there's a deficiency in our conception of file
owne
Anthony Towns writes:
> On Mon, Sep 18, 2000 at 10:15:45PM -0600, Jason Gunthorpe wrote:
> > The idea we struck on was for each package to have a 'urgency serial
> > number' which exists on the ring [0...N]. The difference in the priority
> > serial numbers of any two packages indicates how urge
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Greg> Now a new version of foo comes out, and a new package libfoo2
> Greg> is released but it uses the same configuration file as
> Greg> libfoo1.
>
>
> *BZZZT*. Mistake. New package, new configuration file --
> the postinst should h
Brian May <[EMAIL PROTECTED]> writes:
> Personally (and I realize others do disagree), my feeling is:
>
> - Kerberos 4 is obsolete and should not be used anymore. MIT no longer
> support it. There is only one mainstream application that still
> requires Kerberos 4: AFS. It could be argued that A
Chris Waters <[EMAIL PROTECTED]> writes:
> On Mon, Oct 16, 2000 at 04:23:43PM -0400, Ben Collins wrote:
>
> > Ok, I'm tired of having to track all services that might need to be
> > restarted after a libc6 upgrade. So here's what I am going to do. I want
> > to require all packages that need thi
Ben Collins <[EMAIL PROTECTED]> writes:
> > We need to find a way to not require the restarts. Perhaps the nss modules
> > could provide the old nss functions as versioned 2.0 symbols?
> >
> > (Sigh, this would all go away if people just bumped sonames when they had
> > to.)
>
> This isn't a
[Bcc'd to debian-devel so followups will go to debian-policy]
I don't know if i'm the only one with this problem, but I can never find the
debian docs when I want them. I can never remember which of the following the
file I want is in:
/usr/doc/debian
/usr/doc/developers-referenc
18 matches
Mail list logo
