Re: [RFD]: Question regarding actions to take on --purge of a package.
On 31-Jan-00, 16:44 (CST), Brock Rozen <[EMAIL PROTECTED]> wrote:
> If I understand correctly, remove removes the binaries. Leaves docs, etc.
>
> Right?
Wrong. More explicitly: dpkg removes everything
in /var/lib/dpkg/info/foo.list that isn't also in
/var/lib/dpkg/info/foo.conffiles. The maintainer scripts are expected to
deal with non-conffile configuration files (which won't be in foo.list)
in a consistent manner; likewise (according to current policy) log files
and other detritus.
(I honestly find your question a little frustrating: you're arguing for
a new mechanism when you don't understand the current one.)
> I would think anything the program didn't create (beyond null files) upon
> creation/installation would be considered data.
>
> Be it MySQL databases, Apache logs or whatever else.
There is (in my mind at least, but apparently not yours :-)) a huge
difference between the database files that a user creates via mysql and
the log files it (may) create during operation. I (probably) don't want
it to remove the db files when I purge, but I really don't want to have
to go cleanup all it's damn log files, either.
I understand that Apache (and other webserver) logfiles *are* a
borderline case, because they can be treated as data.
> No, don't make me back it up. My server works just fine on it's RAID-5
> that I don't need back-ups (just one example of why someone wouldn't
> back-up; although it don't protect against every type of data loss).
Not even the most likely...(user error). I'm curious: by default, don't
the Apache logs get rotated and eventually deleted?
> And I still think a configurable uninstall would serve Debian packages
> well. Certainly a mechanism that could be integrated slowly.
>
> Could it hurt?
Yes. My experience is that users find it extremely frustrating to be
asked a bunch questions whose answers are either obvious or unanswerable
("I'm not using this file anymore, and I don't think anybody else is,
but if I delete it and I'm wrong, your system could crash horribly.
Delete?")
Again, I understand why you want to preserve a certain class of log
file, I just think it is an extremely borderline case, and don't think
it needs a new mechanism when it is so easily dealt with.
Beyond this, I just think we'll have to agree to disagree: I'm hardly
the prime mover in Debian policy, if you convince a majority, then I'll
not object (much).
Steve
--
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
Re: [RFD]: Question regarding actions to take on --purge of a package.
Brian May <[EMAIL PROTECTED]> writes: > This is why I particular hate the bug in dpkg that warns the > administrator that empty directories have not been deleted. Usually (always?) this warning is wrong and it will be deleted in the purge process later. Falk
Re: Wait, it *DOES* say all programs! (was Re: Custom undocumented(7)s)
Chris Waters wrote: > Actuallychecking...this seems to be true, and I don't think we > want it to be true. Every program that's found in the default path, > yes, but I was certainly under the impression that we don't want or > need man pages for what might be called "private binaries", > i.e. programs not intended to be run directly -- programs that should > usually be found in /usr/lib/whatsit. > > So, as long as we're discussing the modification of 6.1, perhaps we > should address this issue as well. Unless I'm overlooking something > in policy that already addresses this. Well I don't know, policy paints all library function calls with the same brush: If no manual page is available for a particular program, utility or function and this is reported as a bug on debian-bugs, a symbolic link from the requested manual page to the undocumented(7) manual page should be provided. This symbolic link can be created from debian/rules' like this: The point seems to be, if it's something people would reasonably expect find a man page on, something should be done. -- see shy jo, in New York
Re: Wait, it *DOES* say all programs! (was Re: Custom undocumented(7)s)
Joey Hess <[EMAIL PROTECTED]> writes: > Chris Waters wrote: > > Actuallychecking...this seems to be true, and I don't think we > > want it to be true. Every program that's found in the default path, > > yes, but I was certainly under the impression that we don't want or > > need man pages for what might be called "private binaries", > > i.e. programs not intended to be run directly -- programs that should > > usually be found in /usr/lib/whatsit. > Well I don't know, policy paints all library function calls with the > same brush: True, but library functions are externally visible (at least if you're a programmer), while private binaries generally aren't. It may seem a little strange to argue that some binaries shouldn't have man pages while lib functions should, but that's mostly because we've been so lax about providing man pages for lib functions. I think. :-) > The point seems to be, if it's something people would reasonably > expect find a man page on, something should be done. Yes, that seems reasonable. But I'm afraid it's ambiguous. The question is, what *would* we reasonably expect to find man pages on? Do private binaries fall into that category? I'd say not, but I'm just one opinion cheers -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: Wait, it *DOES* say all programs! (was Re: Custom undocumented(7)s)
Chris Waters wrote: > > The point seems to be, if it's something people would reasonably > > expect find a man page on, something should be done. > > Yes, that seems reasonable. But I'm afraid it's ambiguous. The > question is, what *would* we reasonably expect to find man pages on? > Do private binaries fall into that category? I'd say not, but I'm > just one opinion Sorry, I don't understand what's ambiguous about "if people ask for documentation on it, it should be made available". -- see shy jo
Re: [RFD]: Question regarding actions to take on --purge of a package.
> "Raul" == Raul Miller <[EMAIL PROTECTED]> writes: Raul> And what about files that "belong" to multiple packages? Raul> [And, how do you ensure the fresh install of a new such Raul> package when the old one has been running for some time?] Well, I already experience problems when a file is owned by multiple packages. Take dhcpd and dhdpd-beta for instance (this was a while ago now, but I strongly suspect the problem still exists). Say I have dhcpd-beta installed. I want to install dhcpd instead. So, I say apt-get install dhcpd (I think it use to be called that - now it is dhcp). However, I still have the configuration files for dhcpd-beta installed. How do I fix this? dpkg --purge dhcpd-beta of course! WRONG! When purging dhcpd-beta, it automatically deletes /var/lib/dhcpd, hence breaking the copy og dhcpd that was previously installed. Then again, I seem to remember it being policy or something saying that only one package should claim any file unless the packages conflict. Can anyone provide two packages that do share the same files, and that dont conflict? Raul> The simple solution to letting the administrator know the Raul> package which created the file (which you already see in Raul> place here) is to ensure that the path name has the package Raul> name clearly embedded. Your solution: administrator manually cleans up mess left behind by removing package. My solution: dpkg does it. Raul> Finally, what's the difference between user files and Raul> database files? Location stored? We're currently Raul> experiencing a controversy where creation of a man page is Raul> "too much". In my opinion you're proposing a much tougher Raul> problem. I am afraid you have lost me there. I wasn't proposing to put any files in different locations - I think you were (in you last paragraph). -- Brian May <[EMAIL PROTECTED]>
Re: [RFD]: Question regarding actions to take on --purge of a package.
> "Falk" == Falk Hueffner <[EMAIL PROTECTED]> writes: Falk> Usually (always?) this warning is wrong and it will be Falk> deleted in the purge process later. Should I report filing bugs against packages which don't? I know when I upgraded my computers to potato there were a number of directories which obviously should have been deleted, but weren't. However, I have tossed out the piece of paper I wrote them down on now :-( /usr/lib/texmf/* might have been one, I can't remember right now. It only had one file: ls-R. -- Brian May <[EMAIL PROTECTED]>
Re: [RFD]: Question regarding actions to take on --purge of a package.
On 2 Feb 2000, Brian May wrote:
> dpkg --purge dhcpd-beta
>
> of course!
>
> WRONG! When purging dhcpd-beta, it automatically deletes
> /var/lib/dhcpd, hence breaking the copy og dhcpd that was previously
> installed.
Ok, lets apply this to apache again.
What if another pkg installs files into /var/{log,lib}/apache, or,
/etc/apache? Apache's postinst does an rm -rf on those dirs, and this will
wipe out the files owned by the other pkg. libapache-mod-jserv stored data
into /etc/apache, however, this pkg has since be renamed to jserv, and stores
its config in /etc/jserv. But there could be other cases of this as well.
Would this be a bug on apache? Or a bug on policy? This needs to be
clarified.
BEGIN GEEK CODE BLOCK
Version: 3.12
GCS d- s: a-- c+++ UL P+ L !E W+ M o+ K- W--- !O M- !V PS--
PE++ Y+ PGP++ t* 5++ X+ tv b+ D++ G e h*! !r z?
-END GEEK CODE BLOCK-
BEGIN PGP INFO
Adam Heath <[EMAIL PROTECTED]>Finger Print | KeyID
67 01 42 93 CA 37 FB 1E63 C9 80 1D 08 CF 84 0A | DE656B05 PGP
AD46 C888 F587 F8A3 A6DA 3261 8A2C 7DC2 8BD4 A489 | 8BD4A489 GPG
-END PGP INFO-
Re: [RFD]: Question regarding actions to take on --purge of a package.
> "Adam" == Adam Heath <[EMAIL PROTECTED]> writes:
Adam> What if another pkg installs files into
Adam> /var/{log,lib}/apache, or, /etc/apache? Apache's postinst
Adam> does an rm -rf on those dirs, and this will wipe out the
Adam> files owned by the other pkg. libapache-mod-jserv stored
Adam> data into /etc/apache, however, this pkg has since be
Adam> renamed to jserv, and stores its config in /etc/jserv. But
Adam> there could be other cases of this as well.
If you look at my proposal, it would fix this problem.
Eg, apache would somehow tell dpkg
"I own /etc/apache/{access.conf,httpd.conf,srm.conf}"
package Y would tell dpkg:
"I own /etc/apache/y_thinks_it_is_apache"
When purging apache, dpkg (and not the postinst script) would only
delete the files it knows apache owns. It wouldn't delete any other
file (perhaps an exception could be made for *.bak files).
For instace:
dpkg --purge apache
deletes /etc/apache/{access.conf,httpd.conf,srm.conf}
dpkg --purge Y
deletes /etc/apache/y_thinks_it_is_apache
and then attempts to
(optional step: rm /etc/apache/*.bak)
rmdir /etc/apache
however, assume other file exists, eg /etc/apache/{counter.log,core}
(which both do exist for some reason on my system).
In this case, dpkg wont delete the directory, but warn the
adminstrator somehow that other files still exist that it doesn't know
about.
Adam> Would this be a bug on apache? Or a bug on policy? This
Adam> needs to be clarified.
I think it is a bug in dpkg. dpkg support for files that don't exist
in the *.deb package is non-existant, IMHO, and package maintainers
have been forced to hack out solutions in postrm scripts.
--
Brian May <[EMAIL PROTECTED]>
Re: [RFD]: Question regarding actions to take on --purge of a package.
On Tue, Feb 01, 2000 at 12:44:11AM +0200, Brock Rozen wrote:
> If I understand correctly, remove removes the binaries. Leaves docs, etc.
>
> Right?
No. Remove removes everything which is replaceable, that is,
everything which appears in the original .deb except for files listed
as conffiles. It also does whateven is specified in the {pre,post}rm.
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Donate free food to the world's hungry: see http://www.thehungersite.com/
