Re: /etc/shells management
Manoj Srivastava <firstname.lastname@example.org> wrote:
> On Mon, 08 Sep 2003 11:11:34 +0200, Andreas Metzler <email@example.com> said:
>> Branden Robinson <firstname.lastname@example.org> wrote: [...]
>>> The fact that a non-version-number string literal with shell
>>> redirection operators in it was a valid value of "old-version",
>>> "new-version", "most-recently-configured-version", and so forth,
>>> did not occur to me.
>>> I'd propose a Policy amendment dropping support for this
>>> long-obsolete dpkg behavior, but I reckon I've lost my
>>> Policy-amendment-proposing credentials in your eyes.
>> I would support it.
It is cruft and policy has over 300KB. Afaik policy's purpose is not
to document historical behaviour in dpkg but technical requirements
for packages in Debian.
> Policy does not ask you to cater to ancient versions of
> dpkg; it merely mentions historical behaviour, and you can't
> retroactively go back and change dpkg implementations from way back
The simple fact that it is documented in policy without big fat
markers "Don't implement today, this is *ancient* dpkg, it is useless
today" makes it a suggestion.
I recently modified some postinst and (following policy) added the
nowadays completely useless test for '<unknown>' because I did not
check dpkg's changelog ATM.
[o] Stupid [o] Overzealous [o] Avoidable
> who can see no reason to go back and edit working postinst scripts
> just to remove compatibility with improbably old versions of dpkg
Removing the paragraph from policy would not force you to edit working