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
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
Anthony Towns aj@azure.humbug.org.au 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
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 essential
On Mon, Dec 13, 1999 at 01:08:41AM -0800, Chris Waters wrote:
Anthony Towns aj@azure.humbug.org.au 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
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
Anthony Towns aj@azure.humbug.org.au 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
[following up my own post to cover some points I missed]
Chris Waters [EMAIL PROTECTED] writes:
Anthony Towns aj@azure.humbug.org.au 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,
Anthony Towns aj@azure.humbug.org.au writes:
[1 text/plain; us-ascii (quoted-printable)]
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
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
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 isn't
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 must
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 package to
be
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
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 we
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
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.
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
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
On Wed, Dec 08, 1999 at 09:40:21PM +1000, Anthony Towns wrote:
+
+ p
+Since dpkg will not prevent upgrading of other packages
+while an ttessential/tt package is in an unconfigured
+state, all ttessential/tt must supply all their core
+
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 ttessential/tt package is in an unconfigured
+state, all
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
On Wed, Dec 08, 1999 at 09:33:30AM -0500, Ben Collins wrote:
+Since dpkg will not prevent upgrading of other packages
+while an ttessential/tt package is in an unconfigured
+state, all ttessential/tt must supply all their core
+
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 ttessential/tt package is in an unconfigured
+state,
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
real problem to
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 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
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, 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 able
Anthony Towns aj@azure.humbug.org.au writes:
+Since dpkg will not prevent upgrading of other packages
+while an ttessential/tt package is in an unconfigured
+state, all ttessential/tt must supply all their core
+functionality even when
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 to
Anthony Towns aj@azure.humbug.org.au 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
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 reopen so
On Tue, Nov 23, 1999 at 06:00:32AM -0800, Chris Waters wrote:
Anthony Towns aj@azure.humbug.org.au 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
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
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 50832
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
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 packages
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 will not
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
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* when
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 really
42 matches
Mail list logo
