DragonFly kernel List (threaded) for 2004-03
Re: Unionfs etc Re: Packaging
On Fri, Mar 12, 2004 at 11:23:55AM -0500, Rahul Siddharthan wrote:
> > The only and correct solution is determing wether any other package uses
> > such an directory. There is a reason for empty directories so exist, e.g.
> > think of a chroot directory for a process not wanting any file IO.
> Should have made that clear: I was talking of cases where a directory
> is non-empty before you remove the package, but after you remove all
> files from that package, the directory becomes empty. I wasn't
> talking of removing all empty directories wantonly. I can't think of
> a case where a package needs an empty directory while another optional
> package needs to put files into that directory -- if such cases exist,
> I think they'd be sufficiently rare that we can use a .keep.this dummy
> file inside the directory. The current @dirrm setup just looks like a
> big error-prone mess to me.
We are talking about the same situation here. OpenBSD has recently adjusted
its package tools to automatically remove shared directories once they are
empty. That's makes most @dirrm superfluous. The situation is not that
atypical for extensive systems like GNOME, Python or TeX. It is often not
a hard requirement but a useful hint for the administrator "drop your files
> > Also
> > the location for perl/python modules can be empty once installed and there
> > is no need for ".KEEP_THIS" entries.
> I don't quite see this. Why do perl/python modules need to have empty
> directories? The only python module directories I have (in my home
> area) were created by specific modules -- and the "base" directory was
> created by the setup.py script for the first of those modules. If I
> remove all the modules, I should be able to remove $HOME/lib/python
> with no ill effects. The system lib/python directory of course will
> never be empty unless you remove python totally. I'm not familiar
> with perl.
Sorry, bad wording :) With a new Python installation you might have an
empty site-packages directory. This should not be deleted as it is part of
Python and the prefered location for 3rd party extensions. The situation
for Perl is somewhat similiar.