Re: How to get dpkg to remove directories?
On 11-Jun-02, 15:19 (CDT), Grant Edwards <grante@visi.com> wrote:
> 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.
Apparently Wichert is going to fix that. But there's another case:
configuration files that are managed by the maintainer scripts. Dpkg
has no way to distinguish between those and random files that someone
has dropped into the directory. Also, I'm not sure if dpkg deals with
conffile file "leftovers" (e.g. /etc/foo/options.conf.dpkg-dist).
> 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.
Hmm, never seen that, but probably never tried it, either. Wichert, is
dpkg really special casing files under /etc/ that way? (Don't answer, I
guess I need to go read the bugreports.)
> > 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.
Or removed by postrm script.
> 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.
But my point was that even if you fix them for the your packages,
there's lots of other packages that will generate the same warnings. They're
still gonna call you (assuming you are shipping a whole distribution, and
not just the specific packages.)
> It doesn't matter if you explain in the documentation that
> warnings are normal. Customers don't read documentation.
Oh, don't I know it!
>
> 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.
Then it's not a configuration file, and it shouldn't be under /etc.
> 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.
No, don't do that for /etc/init.d/foo. Every Debian init script is a
configuration file ipso facto, and hiding it will just annoy people. But
*most* people will not edit it. It doesn't hurt anything by being there,
because your package is never going to be the last thing in /etc/init.d,
so the warning issue is irrelevant. But you can (should!) still test for
the /usr/lib/foo/mainscript to see if the package is installed. In
other words, your /etc/cron.daily/foo does:
test -x /usr/lib/foo/mainscript && exec /usr/lib/foo/mainscript
and your /etc/init.d/foo script does (near the top)
test -x /usr/lib/foo/mainscript || exit 0
(It probably seems I'm being inconsistent, by encouranging you to "hide"
your cron.daily script but then discouraging the same thing for init.d.
But I think I'm describing "common practice", and the first feels ok
while the second strikes me as annoying. Hmmm.)
Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: