Raphael Hertzog hert...@debian.org writes:
On Fri, 04 Mar 2011, Jonathan Nieder wrote:
) I suspect others like it, too, but who knows? Patch attached.
Seconds or objections welcome.
Seconded. It's long and I might have missed some inaccuracies but I think
it's an improvement in clarity.
Steve Langasek vor...@debian.org writes:
On Sun, Aug 15, 2010 at 12:25:19PM -0700, Russ Allbery wrote:
I believe they can be in the same state as the pre-dependency itself
for exactly the same reasons, no? Upgrades don't require deconfiguring
packages that depend on the package being
Russ Allbery wrote:
Steve Langasek vor...@debian.org writes:
I might also add at the end:
In such situations, the depended-on package should perform an equivalent
clean-up operation if it's the first package to be removed or purged.
But that may not be unambiguous enough to add any
Raphael Hertzog hert...@debian.org writes:
On Mon, 26 Jul 2010, Russ Allbery wrote:
p
The prgnDEBIAN/prgn directory will not appear in the
file system archive of the package, and so won't be installed
- by prgndpkg/prgn when the package is installed.
+ by
Steve Langasek vor...@debian.org writes:
On Wed, Jul 21, 2010 at 01:52:50PM -0700, Russ Allbery wrote:
+ Sometimes, a package requires another package to be unpacked
+ emand/em configured before it can be unpacked. In this
+ case, the dependent package must specify this
Here's the new version of the patch.
diff --git a/policy.sgml b/policy.sgml
index 0624290..8a70ebf 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -1104,10 +1104,10 @@
/p
p
- Sometimes, a package requires another package to be installed
- emand/em configured before
On Sun, 15 Aug 2010, Russ Allbery wrote:
Raphael Hertzog hert...@debian.org writes:
On Mon, 26 Jul 2010, Russ Allbery wrote:
p
The prgnDEBIAN/prgn directory will not appear in the
file system archive of the package, and so won't be installed
-by prgndpkg/prgn when the
Russ Allbery wrote:
How about this?
p
The ttDepends/tt field should also be used if the
prgnpostinst/prgn or prgnprerm/prgn scripts
require the depended-on package to be unpacked or
configured in order to run, or if the
On Sun, Aug 15, 2010 at 03:24:59PM -0500, Jonathan Nieder wrote:
As Steve pointed out, this is generally going to be a no-op, since if
you're cleaning something up in postrm, you probably already depended on
it because you're using it in postinst.
Example where it is not a no-op: doc-base
Based on Steve’s explanation:
Russ Allbery wrote:
p
The ttDepends/tt field should also be used if the
prgnpostinst/prgn or prgnprerm/prgn scripts
require the depended-on package to be unpacked or
configured in order to run,
Steve Langasek wrote:
On Wed, Jul 21, 2010 at 01:52:50PM -0700, Russ Allbery wrote:
In this
+ case, the dependent package must specify this dependency in
+ the ttPre-Depends/tt control field.
[...]
I think depending package
On Mon, 26 Jul 2010, Russ Allbery wrote:
Here is an updated version of the proposed patch, reflecting additional
feedback. I think we should hopefully be close to a final wording now.
I have reviewed the patch and did not found any problem.
Seconded.
p
The prgnDEBIAN/prgn
On Mon, Jul 26, 2010 at 03:39:30PM -0700, Russ Allbery wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Russ Allbery wrote:
I think we should hopefully be close to a final wording now.
Indeed! All I have left are copy-edits (patch below).
Thanks! Applied to my copy.
@@ -5048,7
(-cc: the bug. Sorry about that tangent.)
Bill Allombert wrote:
Another issue is that only one MTA can be listening on port 25 at any time,
and Debian
does not provide a way to prevent two packages to be configured to listen on
the same
port.
That is a good point, and one that I do not
Steve Langasek vor...@debian.org writes:
I don't think it's a whoops, but it is true that Breaks is asymmetric
and it's specifically the /broken/ package that is deconfigured when the
/breaking/ package is unpacked, and I think Policy should be clear about
this. (Yes, the fact that the
Jonathan Nieder jrnie...@gmail.com writes:
Russ Allbery wrote:
I found the original awkward and hard to puzzle out. How about this:
p
Since ttDepends/tt only places requirements on the order in
which packages are configured, packages in an installation run
are
Here is an updated version of the proposed patch, reflecting additional
feedback. I think we should hopefully be close to a final wording now.
diff --git a/policy.sgml b/policy.sgml
index e5134ed..9e8689e 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -1079,10 +1079,10 @@
/p
p
-
Jonathan Nieder jrnie...@gmail.com writes:
Russ Allbery wrote:
I think we should hopefully be close to a final wording now.
Indeed! All I have left are copy-edits (patch below).
Thanks! Applied to my copy.
@@ -5048,7 +5132,7 @@ Provides: mail-transport-agent
Conflicts:
Russ Allbery wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Aside: is this advice right? Maybe we should be encouraging
Provides: mail-transport-agent
Breaks: mail-transport-agent
Replaces: mail-transport-agent
instead.
[...]
newaliases programs have to match whatever MTA is
Jonathan Nieder jrnie...@gmail.com writes:
If we instead take the Conflicts seriously, then switching between MTAs
requires the following sequences of events:
deconfigure packages that pre-depend or depend on mail-transport-agent
remove the old mail-transport-agent
unpack the new
On Wed, Jul 21, 2010 at 01:37:28PM -0700, Russ Allbery wrote:
p
When one binary package declares a conflict with another
using a ttConflicts/tt field, prgndpkg/prgn will
-refuse to allow them to be installed on the system at the
+refuse to allow them to be
Steve Langasek wrote:
So I think it's better to say:
This is a stronger restriction than ttBreaks/tt, which just
prevents the package listed in the Breaks field from being
configured while the package with the Breaks field is present on
the system.
Avoids
Thank you very much for the detailed review!
Jonathan Nieder jrnie...@gmail.com writes:
Russ Allbery wrote:
p
+ What follows is a summary of all the ways in which maintainer
+ scripts may be called along with what facilities those scripts
+ may rely on being available at
Russ Allbery r...@debian.org writes:
Please review in detail, as this is the first documentation we'll have
of several hairy assumptions involved in maintainer script dependencies.
Here is an updated patch reflecting feedback from Ben Finney and Jonathan
Nieder.
diff --git a/policy.sgml
Russ Allbery wrote:
I found the original awkward and hard to puzzle out. How about this:
p
Since ttDepends/tt only places requirements on the order in
which packages are configured, packages in an installation run
are usually all unpacked first and all
Russ Allbery wrote:
Initial bootstrap, like udebs, feels to me like
something that's outside the intended scope of Policy.
Note to self: beg Neil Williams to help edit a document based on
multistrap.
Jonathan Nieder jrnie...@gmail.com writes:
* postrm does not get called until
Jonathan Nieder jrnie...@gmail.com writes:
Russ Allbery wrote:
Jonathan Nieder jrnie...@gmail.com writes:
* postrm does not get called until pre-dependencies for the new
version are satisfied. So I think it is impossible for
pre-dependencies to be half-installed here.
I believe,
Russ Allbery wrote:
Suppose that you have a package foo 1.0-1 with:
Pre-Depends: bar
and a package foo 2.0-1 that has no pre-dependencies.
[...]
Now you run:
dpkg -i foo_2.0-1.deb
foo 2.0-1 has no pre-dependencies, so the pre-dependency check succeeds.
Installation proceeds
Colin Watson cjwat...@debian.org writes:
The policy manual currently uses the word installed in a couple of
different ways when referring to packages. Sometimes it's speaking quite
loosely, and in this sense is talking about something roughly equivalent
to 'dpkg --install'. However, in some
Hi,
Russ Allbery wrote:
This adds new information to the Summary of ways maintainer scripts are
called section (6.5) stating exactly what maintainer scripts can depend
on when various actions are called.
This is very welcome. Thanks for moving it forward.
Warning: most of what I say below
Russ Allbery writes (Re: Bug#504880: Disambiguate installed for packages):
The current wording does cover the cases of the other scripts. What my
current proposed wording says, summarized, is:
...
This is a very helpful way of presenting it.
postrm (all functions except purge):
All
I think at this point we really need someone from the dpkg team to tell us
what Policy needs to be saying here. This feels like one of those cases
where the best thing to do is just document what dpkg promises to do,
rather than trying to make dpkg match what Policy might be saying. I'd
like to
32 matches
Mail list logo
