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
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
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
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
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
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
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
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
> > 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
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
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
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.
> >
>
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
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:
>
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
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?
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
[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
