Bug#322348: /etc/init.d/apache script wasn't removed by postrm
On Tue, 01 Nov 2005 11:09:27 -0500
Adam Conrad <[EMAIL PROTECTED]> wrote:
> I think you're confusing the first and last columns...
You were right. Thanks; that correction helps. What it says here[1]
confirms it:
The exact format for the "Status:" field is:
Status: Want Flag Status
Where Want may be one of unknown, install, hold, deinstall, purge. Flag
may be one of ok, reinstreq, hold, hold-reinstreq. Status may be one of
not-installed, unpacked, half-configured, installed, half-installed
config-files, post-inst-failed, removal-failed. {...}
...so the 'Status(Want)' field is not the 'Status(Status)'
field. I've misused the term 'deinstalled', or rather 'Status
(deinstalled)'; sorry about that.
Despite this goof, and at the possible risk of offending with further
errata, I'm afraid your correction has thrown out the baby with the
bathwater -- the "baby" being the prior part of my last message about
the 'Status (Status)' field terms being merely contrary, despite
being written as if they were actually contradictory.
To recap, (using some bits just learned about 'Status(Status)'
fields), 'Status(installed)' is defined as ALL files present, and
'Status(not-installed)' is defined as NO files present. Those
definitions are contrary to each other, but common usage of 'not-'
properly indicates a contradiction[2].
Your first post said: "sure it's installed", which does not agree
with respect to those 'Status(Status)' definitions. The error very
probably stems from confused nomenclature in the "Status: Want Flag
Status" data structure.
It matters because these nomenclature bugs will continue to confuse
users. These probably can't be fixed outright, (it's a bit late to
easily change any 'Status(Status)' field names to something better), but the
bugs could (eventually) be identified, acknowledged and documented with
caveats or warnings where appropriate.
NB: this supposed Nomenclature That Breeds Confusion[3] is not an 'apache'
bug, but bugs start where they're found. Which is not to suggest that
right here is the proper forum to continue to address possible new
bugs beyond the point of introduction.
[1] dpkg technical manual
Chapter 1 - Quick summary of dpkg's external interface
1.2 The dpkg status area
/usr/share/doc/libapt-pkg-doc/dpkg-tech.html/ch1.html
...in package 'libapt-pkg-doc'.
[2] This book has a decent recent treatment of contraries vs. contradictions:
Logic made easy / Deborah J. Bennett.
New York : W.W. Norton & Co., 2004.
[3] A favorite example: the electrical terms 'positive' and 'negative',
after the advent of atomic theory, which they predate -- it turned out
the terms have it backwards, in a way. There's a chapter on that in:
Scientists' Nightmares : The Baffling, the Fake, & the Unsolvable
George O. Smith / Putnam Publishing Group, 1972
And a feisty revisionist essay on the same topic:
WHICH WAY DOES THE "ELECTRICITY" REALLY FLOW?
(C)1996 William Beaty
http://www.amasci.com/amateur/elecdir.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#322348: /etc/init.d/apache script wasn't removed by postrm
On 1 Nov 2005 09:07:37 - "Pawel Wiecek" <[EMAIL PROTECTED]> wrote: > > Does the Debian distro's definition of a "config file" include > > executables? > > Debian definition of config file expressly includes everything in /etc. And > yes, startup script is definitely a config file, since system-specific > configuration can be set there. Thanks for the explanation. So it's expected that some users change their '/etc/init.d/' scripts and they don't want 'em removed unless they '-purge' 'em; result being that none of their tweaks and hacks are ever wiped out without permission. It sounds reasonable. So there's two kinds of users, those that change config scripts and those who don't. Hence bugs (or "bugs", depending on one's view) like this -- the naive users are surprised that config code still runs after its package is removed. Possible accommodation: have packages distinguish between config data and config scripts by some arbitrary flag. When a package is uninstalled (but not purged) it does a checksum test on any of its '/etc' config scripts, and if any were changed, it leaves them all intact, (since they might interact), perhaps with a helpful message to the user explaining this. Whereas if no config scripts were changed, then the user belongs to the no-change group, and the uninstaller deletes them all, as they contain no user data and serve no purpose. Note that this would be on a per-package basis, so that a user might want to change (and keep) the config scripts in package 'foo', but not those of package 'bar'. If it turns out that method would break too many useful things, then about all that I can see for it is to leave the code as is, but somehow improve the docs and prompts so that its behavior becomes familiar enough to seem less surprising. Or a third party helper install util (like 'localepurge') could be written for naive users who want to keep a removed package's config data, but not its config scripts. The util would work as described above, except it'd probably have to distinguish scripts from data on the fly. Or maybe somebody'll write a better 'apt' type program someday, with improved names and data structures... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#322348: /etc/init.d/apache script wasn't removed by postrm
A. Costa wrote: > >>>Seconded. It's not installed on my system: >>> >>>% dlocate -s apache | grep Status >>>Status: deinstall ok config-files > [ much confusion about status lines ] I think you're confusing the first and last columns. That "installed | not-installed" stuff goes in the third column, which is the state column. In your case, the state is "config-files", which is basically halfway in between installed and not-installed. The first column is the selection state (what would get set by dselect, for instance), which is more a statement of what you've TOLD the package system to do, not necessarily what it has done. That one can be "install", "deinstall", or "purge", IIRC. ... Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#322348: /etc/init.d/apache script wasn't removed by postrm
On Nov 1, 3:08am, "A. Costa" wrote:
> Lastly, for anyone reading this who knows, a question:
>
> Does the Debian distro's definition of a "config file" include
> executables?
Debian definition of config file expressly includes everything in /etc. And
yes, startup script is definitely a config file, since system-specific
configuration can be set there.
Pawel
--
(___) | Pawel Wiecek -- Coven / Svart -- http://www.coven.vmh.net/ |
< o o > | <[EMAIL PROTECTED]>GPG/PGP info in headers GSM: +48603240006
|
\ ^ / | * * As the people here grow colder I turn to my computer* * |
(") | * * And spend my evenings with it Like a friend -- Kate Bush |
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#322348: /etc/init.d/apache script wasn't removed by postrm
On Fri, 28 Oct 2005 18:59:12 +1000 Adam Conrad <[EMAIL PROTECTED]> wrote: > > Seconded. It's not installed on my system: > > > > % dlocate -s apache | grep Status > > Status: deinstall ok config-files > > Uhh, sure it's installed. Note the "config-files" state. You "removed" > the package, but didn't "purge" it. (dpkg --purge apache, or purge it > in whatever package frontend you use) According to this definition you're right: not-installed No files are installed from the package, it has no config files left, it uninstalled cleanly if it ever was installed. -- dpkg technical manual 1.2 The dpkg status area /usr/share/doc/libapt-pkg-doc/dpkg-tech.html/ch1.html#s1.2 It logically follows that the opposite of "not-installed", where NO files from the package are present, would be all or some files, even just one. Yet given the next definition (from the same source) I'd be correct: installed All files for the package are installed, and the configuration was also successful. It logically follows from the quantifier 'ALL' that just one file missing would mean the package was not installed, just as 51 cards make an incomplete deck. Seems like the above definitions of 'installed' and 'not-installed' are merely _contrary_, and fail to conform to the common usage of the prefix "not-" as a _contradictory_. Note that my apache 'Status' field quoted above uses the term 'deinstall', which the 'dpkg technical manual' alludes to once, but does not define. Here's a definition: % man dpkg | grep -A 2 -n deinstall | head -n 3 75: deinstall 76: The package is selected for deinstallation (i.e. we want to 77- remove all files, except configuration files). By that usage we were both being vague -- the package wasn't 'installed', (since all files weren't there), and it wasn't 'not-installed', (since some were), it was 'deinstalled'. Unfortunately the prefix "de-" in this context has the common usage of "reversing or undoing", which in this context is virtually what the common usage of "not-" means. Oy vey. Aside from that... Perhaps you were implying that I ought to have purged 'apache' -- I usually don't use 'purge', as old config files sometimes have system specific information that comes in handy. Lastly, for anyone reading this who knows, a question: Does the Debian distro's definition of a "config file" include executables? (My definition would be restricted to inert data, and never code; so '/etc/fstab' would be a 'config file', but any setup or maintenance program, such as '/etc/init.d/apache', would not be.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#322348: /etc/init.d/apache script wasn't removed by postrm
Package: apache Version: 1.3.33-8 Followup-For: Bug #322348 Seconded. It's not installed on my system: % dlocate -s apache | grep Status Status: deinstall ok config-files ...and yet: % ls -l /etc/init.d/apache -rwxr-xr-x 1 root root 2159 Jul 31 19:31 /etc/init.d/apache ...which belongs the package: % dlocate /etc/init.d/apache apache: /etc/init.d/apache Resulting in this error as my system boots: apache is not executable, not starting 'dlocate' shows another thing that maybe ought not remain: % dlocate -L apache | nl 1 /etc/apache 2 /etc/apache/conf.d 3 /etc/init.d/apache 4 /etc/logrotate.d/apache 5 /var/log/apache 'logrotate' for an uninstalled program? I think it should be safe to remove #3 & #4... Hope this helps... -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Versions of packages apache depends on: pn apache-common (no description available) ii debconf [debconf-2.0] 1.4.58 Debian configuration management sy ii libc6 2.3.5-7GNU C Library: Shared libraries an ii libdb4.2 4.2.52-20 Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.8-3 XML parsing C library - runtime li ii libmagic1 4.15-2 File type determination library us ii logrotate 3.7.1-2Log rotation utility ii mime-support 3.35-1 MIME files 'mime.types' & 'mailcap ii perl 5.8.7-7Larry Wall's Practical Extraction apache recommends no packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#322348: /etc/init.d/apache script wasn't removed by postrm
Package: apache Version: 1.3.33-7 Severity: minor when i removed apache packages, i saw that the /etc/init.d/apache was always here. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-k7 Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Versions of packages apache depends on: pn apache-common (no description available) ii debconf 1.4.57 Debian configuration management sy ii dpkg 1.13.10Package maintenance system for Deb ii libc6 2.3.5-3GNU C Library: Shared libraries an ii libdb4.2 4.2.52-19 Berkeley v4.2 Database Libraries [ ii libexpat1 1.95.8-3 XML parsing C library - runtime li ii libmagic1 4.12-1 File type determination library us ii logrotate 3.7.1-1Log rotation utility ii mime-support 3.34-1 MIME files 'mime.types' & 'mailcap ii perl 5.8.7-4Larry Wall's Practical Extraction apache recommends no packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
