Re: How to get dpkg to remove directories?
In linux.debian.devel, you wrote:
>> 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.
If I'd known what I was doing, I wouldn't have 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.
Right.
> 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.)
I'm not sure it's been decided exactly what we're going to
ship. I'm trying to keep the pre-installed packages below
100MB, with instructions on how to remove a few packages
(webmin, Perl, etc.) to get it down to 60MB or so. Total
available disk space is going to be 128MB or 256MB.
If the customer has warnings from a package they installed on
their own, then you're right: there's not much I can do about
it.
>> 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!
Sad thing is that I'm as guilty as any of my customers. ;)
>> 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.
[...]
> No, don't do that for /etc/init.d/foo. Every Debian init script is a
> configuration file ipso facto,
That seems really odd to me. I'm sure it's due to years of
habit from dealing with distros where you don't edit things in
/etc/init.d since those scripts all take config info from
/etc/sysconfig or /etc/foobar.conf or somewhere like that.
[...]
> 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.)
It does seem odd that common practice for /etc/init.d and
/etc/cron.daily aren't the same.
--
Grant Edwards grante Yow! Oh, I get it!! "The
at BEACH goes on," huh,
visi.com SONNY??
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: