Seconded, although I don't see much need for examples in this
case.
Bob
--
_
|_) _ |_ Robert D. Hilliard<[EMAIL PROTECTED]>
|_) (_) |_) Palm City, FL USAPGP Key ID: A8E40EB9
Anthony Towns writes:
>
> --FLPM4o+7JoHGki3m
> Content-Type: text/plain; charset=us
On Wed, Dec 08, 1999 at 04:25:23PM +, Peter Naulls wrote:
> Package: debian-policy
>
> In section 2.3.5, "who's" should read "whose".
> who's is short for "who is" (or similar) while whose
> is ownership (like "its" or "hers").
>
> Peter
Corrected in my CVS version; will be fixed in next r
On Wed, Dec 08, 1999 at 04:25:23PM +, Peter Naulls wrote:
> Package: debian-policy
>
> In section 2.3.5, "who's" should read "whose".
> who's is short for "who is" (or similar) while whose
> is ownership (like "its" or "hers").
I second this.
And, since you didn't include a patch:
*** pol
> > > Amend non-free definition (#46522)
> > > * Stalled.
> > > * Proposed by Raul Miller; seconded by Marco d'Itri, Joseph Carter
> > > and Joel Klecker.
> > > * Change definition of non-free to "contains packages which are not
> > > compliant with the DFSG". Currently, non-free incl
On 9 Dec 1999, Chris Waters wrote:
> I'm a little bit afraid that this opens the door to endless debates
> about what the "core functionality" of a package is. For example, I
> would have considered the "core functionality" of the bash package to
> be providing /bin/bash, but someone was trying
Anthony Towns writes:
> +Since dpkg will not prevent upgrading of other packages
> +while an essential package is in an unconfigured
> +state, all essential must supply all their core
> +functionality even when unconfigured. If the package cannot
>
On Wed, Dec 08, 1999 at 10:24:37AM -0700, Jason Gunthorpe wrote:
>
> Personally I would increase the strength of the wording to be more like:
> An essential package is one that can never stop working. This means any
> dpkg abort must leave the package properly functional.
>
> IMHO just being
On Thu, Dec 09, 1999 at 12:19:34AM +1000, Anthony Towns wrote:
> ldso and libc6 are already Essential, so the dynamic linker, and libc6 are
> guaranteed to be available.
If libc6 were Essential, it'd violate policy. And, indeed, it is not:
[EMAIL PROTECTED]:34:15]:pip$ grep-available -sEssential
On Wed, 8 Dec 1999, Ben Collins wrote:
> Ok, then the only complaint I have is the part that says to remove the
> Essential status if it cannot meet the requirements of being usable when
> unconfigured. In those cases, dpkg being able to have a check for
I think this clause should be used to enf
Package: debian-policy
In section 2.3.5, "who's" should read "whose".
who's is short for "who is" (or similar) while whose
is ownership (like "its" or "hers").
Peter
--
Peter Naulls FutureTV Labs Ltd.
Software Engineer [EMAIL PROTECTED]
+
On Thu, Dec 09, 1999 at 01:40:38AM +1000, Anthony Towns wrote:
Understandable.
> Unless you're planning on doing the freaky new interface to dpkg, that
> lets Apt tell it when to configure packages? :)
I'de have Jason eating out of my hand :) Actually I would really like to
see this. I might ha
On Wed, Dec 08, 1999 at 10:22:02AM -0500, Ben Collins wrote:
> For example, if gzip (for some reason) becomes unusable until after it is
> configured, then we have to remove its essential flag (according to this
> proposal). Can you guess how many packages will now have to depend on it,
> or better
On Thu, Dec 09, 1999 at 01:11:12AM +1000, Anthony Towns wrote:
> On Wed, Dec 08, 1999 at 09:58:38AM -0500, Ben Collins wrote:
> > I think this will make the dependency chain even more complex. I agree
> It doesn't actually do anything, it just documents existing caveats.
> >>> Actually it
On Wed, Dec 08, 1999 at 09:58:38AM -0500, Ben Collins wrote:
> I think this will make the dependency chain even more complex. I agree
It doesn't actually do anything, it just documents existing caveats.
>>> Actually it enforces existing caveats. It just seems to be side stepping the
>>> re
On Thu, Dec 09, 1999 at 12:38:56AM +1000, Anthony Towns wrote:
> On Wed, Dec 08, 1999 at 09:33:30AM -0500, Ben Collins wrote:
> > > > > +Since dpkg will not prevent upgrading of other packages
> > > > > +while an essential package is in an unconfigured
> > > > > +
On Wed, Dec 08, 1999 at 09:33:30AM -0500, Ben Collins wrote:
> > > > +Since dpkg will not prevent upgrading of other packages
> > > > +while an essential package is in an unconfigured
> > > > +state, all essential must supply all their core
> > > > +f
On Thu, Dec 09, 1999 at 12:19:34AM +1000, Anthony Towns wrote:
> On Wed, Dec 08, 1999 at 09:00:09AM -0500, Ben Collins wrote:
> > On Wed, Dec 08, 1999 at 09:40:21PM +1000, Anthony Towns wrote:
> > > +Since dpkg will not prevent upgrading of other packages
> > > +while an ess
On Wed, Dec 08, 1999 at 09:00:09AM -0500, Ben Collins wrote:
> On Wed, Dec 08, 1999 at 09:40:21PM +1000, Anthony Towns wrote:
> > +Since dpkg will not prevent upgrading of other packages
> > +while an essential package is in an unconfigured
> > +state, all essent
On Wed, Dec 08, 1999 at 09:40:21PM +1000, Anthony Towns wrote:
> +
> +
> +Since dpkg will not prevent upgrading of other packages
> +while an essential package is in an unconfigured
> +state, all essential must supply all their core
> +funct
On Fri, Dec 03, 1999 at 09:50:43AM -0800, Joseph Carter wrote:
> > I have already made a little (ok, very little) effort in this way,
> > and Ive sent patches to xearth 1.1 so the future version of xearth
> > may be finaly free (+jpeg, +png, -gif)
>
> You can read gifs freely. Writing them is cla
On Fri, Dec 03, 1999 at 07:29:20PM -0800, Joey Hess wrote:
> A proposal for README.Debian (#42554)
> * Old.
> * Proposed by Stephane Bortzmeyer; seconded by Anthony Towns and
> Richard Braakman.
> * Policy doesn't talk about README.Debian right now. This is an
> addtion to policy that
This proposal's discussion time is more or less over. Fortunately,
I think we've more or less reached consensus that it's a good thing.
Here's a hopefully final diff, that also corrects some weird markup
slightly earlier. It incorporates Julian Gibley's suggested wording
changes.
--- - Wed Dec 8
On Fri, Dec 03, 1999 at 08:36:51PM -0800, Joseph Carter wrote:
> On Fri, Dec 03, 1999 at 07:29:20PM -0800, Joey Hess wrote:
> > Editor and sensible-editor
> > * Old.
> > * Proposed on 2 Jun 1999 by Goswin Brederlow.
> > * Instead of having programs use $EDITOR and fall back to editor,
> >
On Fri, Dec 03, 1999 at 08:36:51PM -0800, Joseph Carter wrote:
> On Fri, Dec 03, 1999 at 07:29:20PM -0800, Joey Hess wrote:
> > Section 3.2 should not allow static user ids (except root=0) (#43483)
> > * Stalled.
> > * Proposed by Andreas Jellinghaus; seconded by Joseph Carter.
> > * Policy c
On Fri, Dec 03, 1999 at 08:36:51PM -0800, Joseph Carter wrote:
> > Echo -n (#48247)
> > * Under discussion.
> > * Proposed by Raul Miller; seconded by Joseph Carter.
> > * Amend policy to say /bin/sh must be a POSIX shell, but with the
> > addition that "echo -n" must not generate a newli
On Fri, Dec 03, 1999 at 08:36:51PM -0800, Joseph Carter wrote:
> On Fri, Dec 03, 1999 at 07:29:20PM -0800, Joey Hess wrote:
> > Amend non-free definition (#46522)
> > * Stalled.
> > * Proposed by Raul Miller; seconded by Marco d'Itri, Joseph Carter
> > and Joel Klecker.
> > * Change defin
On Fri, Dec 03, 1999 at 01:33:43PM -0800, Joseph Carter wrote:
> On Wed, Dec 01, 1999 at 02:57:49PM -0700, Jason Gunthorpe wrote:
> > > Perhaps the keyring (entire keyring) should be in non-us rather than
> > > contrib?
> > Why? There is nothing export-controlled about the keyring, if the keyring
>
On Fri, 3 Dec 1999, Joseph Carter wrote:
> > Why? There is nothing export-controlled about the keyring, if the keyring
> > should go anyplace, it would be data/main or just plain main.
> The keyring doesn't serve much purpose without gnupg in non-US/main.
> Since this creates a dependency of so
On Fri, Dec 03, 1999 at 06:54:27PM -0800, Joey Hess wrote:
> Sure, I amend my proposal to use Antti-Juhani's wording.
And I my second for the same.
--
- Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43
- [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DA
> I have already made a little (ok, very little) effort in this way,
> and Ive sent patches to xearth 1.1 so the future version of xearth
> may be finaly free (+jpeg, +png, -gif)
You can read gifs freely. Writing them is claimed to violate a patent
which is held by two seperate companies (an impo
On Wed, Dec 01, 1999 at 02:57:49PM -0700, Jason Gunthorpe wrote:
> > Perhaps the keyring (entire keyring) should be in non-us rather than
> > contrib?
>
> Why? There is nothing export-controlled about the keyring, if the keyring
> should go anyplace, it would be data/main or just plain main.
The
On Fri, Dec 03, 1999 at 11:03:19AM -0600, Manoj Srivastava wrote:
> Free and non-free are a consequence of the *licence*, which
> has little to do with how the package works technically.
Not according to policy. Else gimp-nonfree wouldn't be non-free, the code
contained therein is comple
On Fri, Dec 03, 1999 at 07:29:20PM -0800, Joey Hess wrote:
> Amend non-free definition (#46522)
> * Stalled.
> * Proposed by Raul Miller; seconded by Marco d'Itri, Joseph Carter
> and Joel Klecker.
> * Change definition of non-free to "contains packages which are not
> compliant with
On Tue, Dec 07, 1999 at 02:46:20PM -0800, Joey Hess wrote:
> Here is my revised text for this proposal. I guess it wouldn't hurt to get a
> few seconds for it.
>
> 2.3.2. The maintainer of a package
> --
>
> - Every package must have exactly one maintainer a
Zed Pobre wrote:
> Actually, I kind of have a nit to pick with this, on the grounds
> that a package might not be appropriate for any distribution on the
> grounds of a completely unacceptable license (which I suppose would
> mean that the appropriate distribution is the bitbucket and the
> sta
35 matches
Mail list logo
