What's worse: unowned directories or multiple owners?

[Michael Schwendt]

On Wed, 29 Mar 2006 09:08:47 +0200, Ralf Corsepius wrote:

> On Tue, 2006-03-28 at 20:05 +0200, Michael Schwendt wrote:
> > On Tue, 28 Mar 2006 19:39:30 +0200, Ralf Corsepius wrote:
> > 
> > > On Tue, 2006-03-28 at 10:32 -0700, Orion Poplawski wrote:
> > > > Maybe the third time is the charm:
> > > > 
> > > > I want to install a file into /usr/share/emacs/site-lisp/ but I don't 
> > > > want to Requires: /usr/share/emacs/site-list/.
> > > It would have to be
> > > Requires(pre): usr/share/emacs/site-list
> > > because otherwise rpm won't be able to handle this correctly.
> > 
> > $ repoquery --whatprovides /usr/share/emacs/site-lisp
> > desktop-file-utils-0:0.10-6.1.i386
> > subversion-0:1.3.0-4.2.i386
> > autoconf-0:2.59-7.noarch
> > emacs-el-0:21.4-14.i386
> > libidn-0:0.6.2-1.1.i386
> > emacs-common-0:21.4-14.i386
> > fedora-rpmdevtools-0:1.5-1.fc5.noarch
> > gforth-0:0.6.2-6.fc5.i386
> > flim-0:1.14.7-3.noarch
> > 
> > $ repoquery --whatprovides /usr/share/emacs
> > emacs-el-0:21.4-14.i386
> > emacs-leim-0:21.4-14.i386
> > emacs-common-0:21.4-14.i386
> > fedora-rpmdevtools-0:1.5-1.fc5.noarch
> > gforth-0:0.6.2-6.fc5.i386
> > 
> > All of these packages claim that they provide Emacs' data directory and
> > would satisfy above "Requires(pre)". This is is harmless as long as you
> > get what you want:
>
> It's not harmless: It adds a dependency on a package providing this
> directory. Not using a dependency on the directory, but simply owning it
> would make this package independent of any package providing this
> directory.

You misunderstood me completely. Let me rephrase. There are multiple
packages which include the /usr/share/emacs directory. So, currently any
dependency on that directory would pull in an arbitrary package which
provides this directory (shortest pkg name wins in Yum). What does this
mean for any package which would "Requires(pre): /usr/share/emacs"? You
can only expect to get the directory, not any content from Emacs' and not
any directory hierarchy either. That's what's harmless about making
multiple packages "own" this directory. Several packages do it
already. Adding another one won't make it worse.

> This is nasty when a package actually is independent of any emacs
> variant and only carries some convenience macros, which are useful for
> emacs users (For example, autoconf is one of these packages)
> 
> In this case, the "Requires" would be wrong.

Well, not wrong at all semantically. Simply assume that "/usr/share/emacs
belongs to Emacs, and no other package should (better: must) mess with
Emacs' directories". Now, if you create multiple packages which claim they
are the owner of /usr/share/emacs, this is wrong.

It might be possible to fix this at the level of RPM, so packagers don't
need to deal with this. E.g. by implementing automatic %ghost
directories. Any non-existing directories needed by a package and not
included in its %files list, would be created, added to a list of orphaned
directories and tied to the package NEVR in an "adopted by"
relationship. These directories would not be seen at the resolver level.
A package which really includes those directories explicitly would
override the ownership and access privileges as usual. And during
removal, for the last package which has the directories listed as orphans,
they could be deleted if no other package owns them.

> > > Of cause there exists the permission's issue on multiply owned dirs, but
> > > if packages are packaged correctly and don't try to play tricks with
> > > ownerships/permissions, this should be a non-issue.
> > 
> > What works with /usr/share/emacs may fail with other directories.
>
> Yes, but this question was on "/usr/share/emacs"

And that's why I wrote it's harmless. Nevertheless, it's important to
understand that as soon as more than one package in a transaction provides
a directory, when creating a dependency on a directory you cannot expect
getting more than "at least an empty directory provided by an arbitrary
package". E.g. "Requires(pre): /usr/share/icons/hicolor/" is no guarantee
to get any hicolour icons.