Raphael Hertzog 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.
Thanks!
Wit
Hi,
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.
Cheers,
--
Raphaël Hertzog ◈ Debian Deve
Russ Allbery wrote:
> Does that look okay?
Yes, the version in branch 504880-rra looks good to me (with one
tweak:
--- a/policy.sgml
+++ b/policy.sgml
@@ -4027,5 +4027,5 @@ fi
in postrm purges the debconf
configuration for the package
if debconf
Jonathan Nieder writes:
> Russ Allbery wrote:
>> Steve Langasek 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 unam
Russ Allbery wrote:
> Steve Langasek 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 value here
Steve Langasek 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 upgraded, so if yo
On Sun, Aug 15, 2010 at 12:25:19PM -0700, Russ Allbery wrote:
> > Does dpkg provide any guarantee that the dependencies of the
> > pre-dependency are also present at this point? If it doesn't, I think
> > that should be considered a bug in dpkg, since you may be invoking a
> > command that links a
Based on Steve’s explanation:
Russ Allbery wrote:
>
> The Depends field should also be used if the
> postinst or prerm scripts
> require the depended-on package to be unpacked or
> configured in order to run, or if the dependend
Steve Langasek wrote:
> This is an obsolete example, doc-base now uses a trigger as it ought to and
> the install-docs command is now a no-op (+ a warning message) when called
> from a maintainer script. :-)
>
> Do you have an example of using Suggests: in this way that *shouldn't* be
> converted
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
Hi Jonathan,
On Sun, Aug 08, 2010 at 07:27:44PM -0500, Jonathan Nieder wrote:
> > Does dpkg provide any guarantee that the dependencies of the pre-dependency
> > are also present at this point?
> Sure: that is part of what it means to configure a package.
> Except *new* dependencies of an upgrad
On Sun, Aug 15, 2010 at 02:57:18PM -0500, Jonathan Nieder wrote:
> Russ Allbery wrote:
>
> > How about this?
> >
> >
> > The Depends field should also be used if the
> > postinst or prerm scripts
> > require the depended-on package to be unpacked or
Russ Allbery wrote:
> Jonathan Nieder writes:
>> My real question was: does this ever happen in the real world?
>
>> - doc-base already removes any remaining state when *it* is purged
>> - debconf does not, but that is a bug. In practice, debconf is
>>almost never uninstalled.
>
>> My worr
Jonathan Nieder writes:
> All right, Recommends then. :)
> My real question was: does this ever happen in the real world?
> - doc-base already removes any remaining state when *it* is purged
> - debconf does not, but that is a bug. In practice, debconf is
>almost never uninstalled.
> My
Russ Allbery wrote:
> Jonathan Nieder writes:
>> Russ Allbery wrote:
>>> The Depends field should also be used if
[...]
>>> the dependend-on package
>>> is desirable for cleanup done by postrm.
>
>> I guess I am confused; when
Jonathan Nieder writes:
> Russ Allbery wrote:
>> How about this?
>>
>>
>> The Depends field should also be used if the
>> postinst or prerm scripts
>> require the depended-on package to be unpacked or
>> configured in order to run,
Russ Allbery wrote:
> How about this?
>
>
> The Depends field should also be used if the
> postinst or prerm scripts
> require the depended-on package to be unpacked or
> configured in order to run, or if the dependend-on packag
On Sun, 15 Aug 2010, Russ Allbery wrote:
> Raphael Hertzog writes:
> > On Mon, 26 Jul 2010, Russ Allbery wrote:
>
> >>
> >> The DEBIAN directory will not appear in the
> >> file system archive of the package, and so won't be installed
> >> -by dpkg when the package is installed.
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 @@
- Sometimes, a package requires another package to be installed
- and configured before it can b
Steve Langasek writes:
> On Wed, Jul 21, 2010 at 01:52:50PM -0700, Russ Allbery wrote:
>> + Sometimes, a package requires another package to be unpacked
>> + and configured before it can be unpacked. In this
>> + case, the dependent package must specify this dependency in
>> +
Raphael Hertzog writes:
> On Mon, 26 Jul 2010, Russ Allbery wrote:
>>
>>The DEBIAN directory will not appear in the
>>file system archive of the package, and so won't be installed
>> - by dpkg when the package is installed.
>> + by dpkg when the package is unpacked
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 Pre-Depends control field.
[...]
> I think "depending pack
On Wed, Jul 21, 2010 at 01:52:50PM -0700, Russ Allbery wrote:
> diff --git a/policy.sgml b/policy.sgml
> index 847f716..eb458fe 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -1079,10 +1079,10 @@
>
>
>
> - Sometimes, a package requires another package to be installed
> -
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.
>
> The DEBIAN directory
On Mon, Jul 26, 2010 at 03:39:30PM -0700, Russ Allbery wrote:
> Jonathan Nieder 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 +5
Jonathan Nieder 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 mail-transport-agent
Russ Allbery wrote:
> Jonathan Nieder 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 actually b
Russ Allbery wrote:
[...]
> (a common
> situation when upgrading shared libraries and their
> corresponding development packages)
[...]
> That moves the whole thing into a footnote and gives a more specific
> example.
Nice.
Jonathan Nieder 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: mail-transport-agent
>> Re
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).
> +++ b/policy.sgml
[...]
> +The unpacked files may be
> + partly from the new version or partly missing, so
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 @@
-
Jonathan Nieder writes:
> Russ Allbery wrote:
>> I found the original awkward and hard to puzzle out. How about this:
>>
>>
>>Since Depends only places requirements on the order in
>>which packages are configured, packages in an installation run
>>are usually all u
Jonathan Nieder writes:
> | Pre-dependencies will be
> | at least unpacked following the same rules as above, except
> | they may be only "Half-Installed" if an upgrade of the
> | pre-dependency failed.
> Maybe a footnote would be appropriate - s
Steve Langasek 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 package manager n
Steve Langasek wrote:
> So I think it's better to say:
>
> This is a stronger restriction than Breaks, 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 refer
On Wed, Jul 21, 2010 at 01:37:28PM -0700, Russ Allbery wrote:
> >>
> >>When one binary package declares a conflict with another
> >> using a Conflicts field, dpkg will
> >> -refuse to allow them to be installed on the system at the
> >> +refuse to allow them to be unpac
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.
> Installatio
Jonathan Nieder writes:
> Russ Allbery wrote:
>> Jonathan Nieder 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, from what Ian said, that
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 writes:
>> * postrm does not get called until pre-dependencies for the
Russ Allbery wrote:
> I found the original awkward and hard to puzzle out. How about this:
>
>
> Since Depends only places requirements on the order in
> which packages are configured, packages in an installation run
> are usually all unpacked first and all configu
Russ Allbery 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 b/policy.sgml
index
Jonathan Nieder writes:
>>
>> - For this reason packages in an installation run are usually
>> - all unpacked first and all configured later; this gives
>> - later versions of packages with dependencies on later
>> - versions of other packages the opportunity to have the
Thank you very much for the detailed review!
Jonathan Nieder writes:
> Russ Allbery wrote:
>>
>> + 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 that time.
Hi again,
Continuing where I left off.
>
> Details of unpack phase of installation or upgrade
[...]
> @@ -4540,31 +4595,29 @@
>
>
>
> - For this reason packages in an installation run are usually
> - all unpacked first and all configured later; thi
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 be
Colin Watson 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 other cases it'
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.
> postr
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 h
On Sat, Feb 14, 2009 at 09:50:49PM +0100, Kurt Roeckx wrote:
> On Sat, Feb 14, 2009 at 12:16:16PM -0800, Russ Allbery wrote:
> >
> > I think this is another aspect of the same point above? My understanding
> > from the discussion and the clarified text that Raphael sent is that
> > postrm can alw
On Sat, Feb 14, 2009 at 12:16:16PM -0800, Russ Allbery wrote:
> Kurt Roeckx writes:
>
> >> +If there is a circular dependency among packages being installed
> >> +or removed, installation or removal order honoring the
> >> +dependency order is impossible, requiring the dependency loop
Kurt Roeckx writes:
>> + If there is a circular dependency among packages being installed
>> + or removed, installation or removal order honoring the
>> + dependency order is impossible, requiring the dependency loop be
>> + broken at some point and the dependency requirements
> + If there is a circular dependency among packages being installed
> + or removed, installation or removal order honoring the
> + dependency order is impossible, requiring the dependency loop be
> + broken at some point and the dependency requirements violated
> + fo
Raphael Hertzog writes:
> We don't want that, feel free to reword that part to frighten people
> that would like to use it just because that sentence says you can rely
> on it. :)
I re-read this whole section while applying your patch and decided that
the wording of the whole section could be i
On Wed, Feb 11, 2009 at 08:27:57PM -0800, Russ Allbery wrote:
> Raphael Hertzog writes:
>
> > Please find a proposed patch in attachment. Feel free to reword/improve
> > if needed.
>
> Is the reason why you can't rely on configured for the prerm case the same
> reason why you can't rely on it fo
On Wed, 11 Feb 2009, Russ Allbery wrote:
> Is the reason why you can't rely on configured for the prerm case the same
> reason why you can't rely on it for the postinst case: because of breaking
> circular dependencies and choosing one package to deconfigure first? It
No, I believe it's a design
Raphael Hertzog writes:
> Please find a proposed patch in attachment. Feel free to reword/improve
> if needed.
Is the reason why you can't rely on configured for the prerm case the same
reason why you can't rely on it for the postinst case: because of breaking
circular dependencies and choosing
On Wed, Feb 11, 2009 at 11:31:34AM +0100, Raphael Hertzog wrote:
> diff --git a/policy.sgml b/policy.sgml
> index f5c6818..8727be1 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -4323,10 +4323,17 @@ Build-Depends: foo [!i386] | bar [!amd64]
> The Depends field should also be used
Hi,
On Sun, 01 Feb 2009, Russ Allbery wrote:
> There isn't any further discussion of this in the bug log, and I don't
> think there was a reply outside of the bug log. I agree with Colin that
> simply changing present to unpacked is potentially confusing, but I would
> like to clarify the case fo
Colin's original patch had one second from Raphael and it looks good to me
as well, so I think we're about ready to commit this for the next Policy
release. I also added this hunk based on the bug discussion:
@@ -4285,8 +4285,8 @@ Build-Depends: foo [!i386] | bar [!amd64]
removal order
On Sun, 09 Nov 2008, Colin Watson wrote:
> > > There is also:
> > > The `Depends' field should also be used if the `postinst',
> > > `prerm' or `postrm' scripts require the package to be present in
> > > order to run. Note, however, that the `postrm' cannot rely on
>
On Sat, Nov 08, 2008 at 06:33:30PM +0100, Raphael Hertzog wrote:
> On Fri, 07 Nov 2008, Colin Watson wrote:
> > I've attached a patch, and am seeking seconds for this proposal. Please
> > double-check it for correctness, particularly the change in the
> > definition of Breaks; I have only verified
On Fri, 07 Nov 2008, Colin Watson wrote:
> I've attached a patch, and am seeking seconds for this proposal. Please
> double-check it for correctness, particularly the change in the
> definition of Breaks; I have only verified that against an old mail from
> Ian proposing the design of this field
>
On Fri, Nov 07, 2008 at 09:26:05PM +0100, Kurt Roeckx wrote:
> On Fri, Nov 07, 2008 at 07:13:18PM +, Colin Watson wrote:
> > The policy manual currently uses the word "installed" in a couple of
> > different ways when referring to packages.
>
> Sometimes it's also using "present" while it prob
On Fri, Nov 07, 2008 at 07:13:18PM +, Colin Watson wrote:
> Package: debian-policy
> Version: 3.8.0.1
> Severity: wishlist
>
> The policy manual currently uses the word "installed" in a couple of
> different ways when referring to packages.
Sometimes it's also using "present" while it probabl
Package: debian-policy
Version: 3.8.0.1
Severity: wishlist
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'. How
65 matches
Mail list logo
