Bug#504880: Disambiguate "installed" for packages
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 that against an old mail from
> > Ian proposing the design of this field
> > (http://lists.debian.org/debian-devel/1997/10/msg00643.html), not
> > against the current implementation.
> Seconded. I agree that it's misleading and ought to be fixed. The part
> concerning Breaks looks right from a quick glance in dpkg's source.
Thanks for the sanity-check.
> On Fri, 07 Nov 2008, Kurt Roeckx wrote:
> > Sometimes it's also using "present" while it probably also means unpacked.
> I would like to fix those too.
> > For instance:
> > some packages may
> > not be able to rely on their dependencies being present when being
> > installed or removed
> > You also didn't change that installed it seems?
> Given that intallation is unpacking + configuration, and that
> configuration is mainly running the postinst, and that the
> postinst configure can rely on dependencies being unpacked, I think we
> should also change installed into unpacked here.
OK, I'm persuaded on this count.
> > 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
> > any non-essential packages to be present during the `purge'
> > phase.
> Ack to change s/present/unpacked/g here too.
I think this would be somewhat confusing. I know that the statement is
strictly logically correct with "unpacked", but it seems as though it
would imply to many readers that the package is *only* unpacked, not
also configured. In the absence of dependency loops, Depends should
guarantee that the depended-upon package is configured rather than
merely unpacked while the depending package's postinst runs; I'm not
sure about prerm and postrm.
I feel that this may be too fine a distinction to draw in this paragraph
without being confusing, and it would be better left non-specific.
Colin Watson [email@example.com]