[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to get dpkg to remove directories?



>>  1) I am not willing to ship a package that generates warning
>>     messages when it's removed.  Warning messages generate
>>     calls to tech support, and that costs money.
>> 
>>  2) After my package has been purged, I don't want any files or
>>     empty directories left over.  Perhaps it's just me, but
>>     this would seem to be the obvious expectation of the
>>     customer.
> 
> Let's distinguish between "removed" and "purged" (you may be doing so
> already, in which case it's me that's confused).
> 
> Removed: all non-configuration files deleted. 
> 
> Purged: all traces of package removed.
> 
> The warnings you're referring to in 1 are because the directory is
> unique to the package, and the dpkg --remove process wants to delete
> it, but it can't because still has files in it (Yes, I know, already
> explained, but I'm trying to pull stuff together here.)

Right.  IMHO, there should be no warning at that point.  Since
the conf files are supposed to stay there, dpkg shouldn't be
trying to remove the directory containing them.  That appears
to be a known bug -- I just need to avoid it.

> In this case, those files are configuration files (either
> conffiles in the package, or non-packages files
> generated/managed (presumably) by the {pre,post}{inst,rm}
> scripts.

Well, originally the files causing problems were neither.  My
initial problems were with package file that were under /etc
that were not marked as conffiles.  I have since learned that
this is a no-no.

Apparently "dpkg --remove" won't remove the files under /etc
because they're _supposed_ to be conffiles, but then "dpkg
--purge" doesn't remove them because they're not declared as
conffiles.  IOW words the criteria for decided what is a
"conffile" is different in the --remove operation than it was
in the --purge operation.  This results in files and
directories that don't get removed.

> When you "dpkg --purge", the files are deleted (either by dpkg
> or by the scripts) before dpkg tries (again) to delete the
> directories, and no warnings are generated.

Correct -- as long as the files were all declared as conffiles
in debian/conffiles.

>> AFAICT, I can avoid both problems by not creating a directory
>> under /etc for my config files.
> 
> Yep, true. But those warnings are completely normal,

I'm not willing to accept "normal warnings".  If there's
nothing wrong, I don't want a warning.

> if annoying. Any Debian admin is going to be used to them.

My customers are probably going to be new to Debian
administration.  If they're told to use "dpkg --remove" or
"dpkg --purge" and it generates warnings, then tech support
will end up handling calls.  Tech support will log incidents
against my stuff because it's generating warning messages when
there's nothing wrong.  I have to explain why and then close
the incidents.

It doesn't matter if you explain in the documentation that
warnings are normal.  Customers don't read documentation.

> Playing games with your particular package isn't going to get
> rid of them.

If I play the games right, it will get rid of them for my
package.  ;)

>> I'm still not convinced that files in /etc/init.d and
>> /etc/cron.daily should conffiles.  They're not supposed to be
>> edited: that's why I created conffiles under /etc.
> 
> Debian has decided that those files are configuration files.
> You've provided configuration externally, but others do not,
> and that's the way it is. On the other hand, if
> 
> Now, there is nothing to prevent you from supplying a
> cron.daily script that consists solely of 
> 
> 	#! /bin/sh
>     test -x /usr/lib/mystuff/realscript && exec /usr/lib/mystuff/realscript
> 
> to make it clear that you really don't want it edited. In fact,
> that is what you *should* do, if, as you claim, the script
> being run is not supposed to be edited.

It's my intent that it not be edited.  Everything site specific
is in /etc/<whatever>.conf (or /etc/<whatever>/config -- I've
tried it both ways.  

It seems a bit baroque: /etc/rcS.d/foo is a link to
/etc/init.d/foo which does nothing but execute
/usr/lib/foo/init.sh. Oh well.  If "dpkg --remove" and "dpkg
--purge" don't generate any warnings, I'm happy.

> As far as the init.d scripts go, they can test for the same thing (to
> determine that the package has been removed), and so far as editing
> it goes, put in a comment at the beginning that says "# Configure in
> /etc/foo.conf" and don't worry about it.

Thanks for the pointers.

-- 
Grant Edwards                   grante             Yow!  An INK-LING? Sure --
                                  at               TAKE one!! Did you BUY any
                               visi.com            COMMUNIST UNIFORMS??


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: