On Mon, Dec 13, 1999 at 01:20:03AM -0800, Chris Waters wrote:
> I'm a lot more sympathetic to this objection than I am to AT's,
> though. Fixing all the dselect methods would certainly be a Good
> Thing. :-)
That is an easy one. Come up with a way to get rid of all the dselect
methods expect for
On Mon, Dec 13, 1999 at 01:08:41AM -0800, Chris Waters wrote:
> Anthony Towns writes:
> > And, gee, shock horror, I'll say the exact same thing I said last time
> > you mentioned this, and that is that it's much more alike things that
> > -policy discusses that things the packaging-manual discusse
Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> On Sun, Dec 12, 1999 at 12:32:08AM -0800, Chris Waters wrote:
> > The downside is, of course, that dpkg isn't very good at ordering
> > things, but again, that's a flaw in dpkg, and I think we'd be better
> > off trying to address that, not just for e
Anthony Towns writes:
> And, gee, shock horror, I'll say the exact same thing I said last time
> you mentioned this, and that is that it's much more alike things that
> -policy discusses that things the packaging-manual discusses.
Yes, I remember. I thought you were suggesting that we move both
On Sun, 12 Dec 1999, Anthony Towns wrote:
> On Sun, Dec 12, 1999 at 12:32:08AM -0800, Chris Waters wrote:
> > The downside is, of course, that dpkg isn't very good at ordering
> > things, but again, that's a flaw in dpkg, and I think we'd be better
> > off trying to address that, not just for es
On Sun, Dec 12, 1999 at 12:32:08AM -0800, Chris Waters wrote:
> But ok, if you don't like that, then I'll go back to what I said the
> first time this came up: this belongs in the packaging manual, not
> policy.
And, gee, shock horror, I'll say the exact same thing I said last time
you mentioned t
[following up my own post to cover some points I missed]
Chris Waters <[EMAIL PROTECTED]> writes:
> Anthony Towns writes:
> > And make dpkg's ordering rules more strict, for no good reason.
> No good reason? How about the very good reason that these packages
> are essential, and if they aren'
Anthony Towns writes:
> And make dpkg's ordering rules more strict, for no good reason.
No good reason? How about the very good reason that these packages
are essential, and if they aren't handled strictly and carefully, we
have problems. As we've just seen.
But ok, if you don't like that, th
On Sat, Dec 11, 1999 at 01:09:29AM -0800, Chris Waters wrote:
> > On Fri, Dec 10, 1999 at 02:06:47AM -0800, Chris Waters wrote:
> > > Furthermore, it occurs to me that the problem isn't just essential
> > > packages. If libc6 fails to work during an upgrade, we're equally bad
> > > off, but libc6
On Sat, Dec 11, 1999 at 01:09:29AM -0800, Chris Waters wrote:
> Here's a thought: the system should actually *pre*-depend on packages
> that are required by the packaging system itself. But essential
> packages are treated (at least by dpkg) as universal dependencies, not
> universal pre-dependenc
Anthony Towns writes:
> [1 ]
> On Fri, Dec 10, 1999 at 02:06:47AM -0800, Chris Waters wrote:
> > Furthermore, it occurs to me that the problem isn't just essential
> > packages. If libc6 fails to work during an upgrade, we're equally bad
> > off, but libc6 isn't essential. So, the proposal is
On Thu, 9 Dec 1999, Raul Miller wrote:
> > Unfortunately, there are some failure modes we don't have enough
> > control over.
On Thu, Dec 09, 1999 at 01:41:51PM -0700, Jason Gunthorpe wrote:
> This is the only point during dpkg's operation where a failure of dpkg is
> catastrophic. IMHO essential
On Thu, 9 Dec 1999, Anthony Towns wrote:
> How about coming up with something better then?
The mechanism APT uses is that Essential packages implicitly make their
dependencies also Essential for installation order - this means things
like libc6 are unpacked and configured immediately.
IHMO this
On Thu, 9 Dec 1999, Raul Miller wrote:
> Unfortunately, there are some failure modes we don't have enough
> control over.
This is the only point during dpkg's operation where a failure of dpkg is
catastrophic. IMHO essential packages should make a 'best effort' to
ensure that they have the highe
On Thu, Dec 09, 1999 at 02:12:54PM +1000, Anthony Towns wrote:
> Finishing unpacking isn't exactly a dpkg abort, though. Maybe
> `This means the package must be functional even before it has been
> configured when upgrading and after any dpkg abort.' ?
Unfortunately, there are some failure modes w
On Fri, Dec 10, 1999 at 02:06:47AM -0800, Chris Waters wrote:
> Furthermore, it occurs to me that the problem isn't just essential
> packages. If libc6 fails to work during an upgrade, we're equally bad
> off, but libc6 isn't essential. So, the proposal is not only
> ambiguous and redundant, but
Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> 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 packag
On Wed, Dec 08, 1999 at 12:37:44PM -0500, Ben Collins wrote:
> 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
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
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
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 Tue, Nov 23, 1999 at 06:00:32AM -0800, Chris Waters wrote:
> Anthony Towns writes:
> > Wichert, Chris, did this or my previous mail answer your objections,
> > or...?
> You yourself admitted that this is more of an explanatory thing than
> actual policy (after all, the bug in bash is a bug with
On Tue, Nov 23, 1999 at 02:54:56PM +, Julian Gilbey wrote:
> On Tue, Nov 23, 1999 at 11:02:24PM +1000, Anthony Towns wrote:
> > close 50832
> > reopen 50832
>
> Huh?!
Amendment
[...]
DD/MM/YYY] ...". Actually it might be better to close the
proposal and reop
Anthony Towns writes:
> Wichert, Chris, did this or my previous mail answer your objections,
> or...?
Well, you did a good job of explaining, and I have a better idea of
what you're *trying* to do now, but I'm still not sure this is the
right way.
You yourself admitted that this is more of an e
On Tue, 23 Nov 1999, Raul Miller wrote:
> > BTW: I hope this clarification about essential will help APT not to be so
> > paranoid by not configuring every essential package just after unpacking
> > them. If APT is changed in this way, I guess upgrades will be as smooth
> > and fast as they can r
On Tue, Nov 23, 1999 at 10:53:57AM -0500, Raul Miller wrote:
> On Tue, Nov 23, 1999 at 02:54:56PM +, Julian Gilbey wrote:
> > But: I just realised. For bash (or whatever essential packages
> > provide /bin/sh and /bin/perl), the situation is far worse: what
> > happens if a package is *removed
On Tue, Nov 23, 1999 at 02:54:56PM +, Julian Gilbey wrote:
> But: I just realised. For bash (or whatever essential packages
> provide /bin/sh and /bin/perl), the situation is far worse: what
> happens if a package is *removed* when the symlink is not in place
> (because the package is not prop
On Tue, Nov 23, 1999 at 11:02:24PM +1000, Anthony Towns wrote:
> close 50832
> reopen 50832
Huh?!
> +Since dpkg will upgrade other packages while an _essential_
> +package is in an unconfigured state, all _essential_ packages must
I think "Since dpkg might upgrade ..." or "Since dpkg wil
I'm Cc'ing this message to debian-apt, to ask if the following
addittion to policy has any hidden ramifications that might
make it a bad idea.
On Tue, Nov 23, 1999 at 03:25:00PM +0100, Santiago Vila wrote:
> On Tue, 23 Nov 1999, Anthony Towns wrote:
>
> > +Since dpkg will upgrade other packag
On Tue, 23 Nov 1999, Anthony Towns wrote:
> +Since dpkg will upgrade other packages while an _essential_
This "will" should be really "may".
> +package is in an unconfigured state, all _essential_ packages must
> +supply all their core functionality even when un
close 50832
reopen 50832
retitle 50832 [AMENDMENT 1999/11/23] Clarify meaning of Essential: yes
thanks
This proposal has been seconded by Raul and Espy, which gives it enough
seconds to be an amendment.
(I've changed the text of the amendment to, hopefully, be a little
clearer. I trust it hasn't
Processing commands for [EMAIL PROTECTED]:
> close 50832
Bug#50832: [PROPOSED] Clarify meaning of Essential: yes
Bug closed, ack sent to submitter - they'd better know why !
> reopen 50832
Bug#50832: [PROPOSED] Clarify meaning of Essential: yes
Bug reopened, originator not changed.
> retitle 508
44 matches
Mail list logo
