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. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
