[vbox-dev] VirtualBox-4.2 can no longer be installed on Fedora 18, due to a directory ownership conflict

Michel Alexandre Salim salimma at fedoraproject.org
Sat Nov 3 09:46:58 PDT 2012

Hash: SHA1

Hi Michael,

On 02/11/2012 16:50, Michael Thayer wrote:
> Hello Michel,
> On 11/02/2012 04:29 AM, Michel Alexandre Salim wrote: [...]
>> On 30/10/2012 22:00, Michael Thayer wrote:
> [...]
>>> Does changeset 43768[1] look right to you?
> [...]
>> The changes look good, but - having not tested it yet or seen
>> the full .spec file after the change - you might need to add
>> runtime dependencies on more packages that provide
>> /usr/share/icons/hicolor and /usr/share/mime:
>> $ rpm -qf /usr/share/mime /usr/share/icons/hicolor | grep -v
>> fedora shared-mime-info-1.0-5.fc18.x86_64 
>> hicolor-icon-theme-0.12-5.fc18.noarch
> I wonder whether this is necessary (I have to say that I am not
> the person who wrote the RPM spec file)?  My thinking is as
> follows: since those directories are created (but their ownership
> not claimed) by our spec file, they - and the files in them -
> should be created when the RPM is installed if they do not already
> exist, without causing problems if the packages claiming ownership
> are installed later.  However, the only situation in which
> shared-mime-info and hicolor-icon-theme are likely not to be
> installed is if no complete desktop environment is installed. In
> this case the files we install into those directories are harmless 
> but useless, and as long as there isn't a consumer for them,
> pulling in shared-mime-info and hicolor-icon-theme will not make
> them any more useful, so we don't really gain anything from
> depending on those packages.  What is more, if we did try to pull
> them in we would have to check whether the package names are the
> same in all RPM-based distributions which we support and if not
> hack our spec file to do the right thing.
The reasoning is correct w.r.t. installation; however, on
uninstallation those directories will not be removed, even if they are
empty, if nobody claims them.

That being said, this will only be a problem for people who install
VirtualBox on systems without FreeDesktop-compliant desktops, which
strikes me as rather unlikely, so it's still better than claiming
directories and then getting file permission conflicts.

When will such a fixed release be made available? There's a ChromeOS
virtual machine image I've been meaning to test that, it seems, only
VBox handles correctly.


- -- 
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

Email:  salimma at fedoraproject.org  | GPG key ID: A36A937A
Jabber: hircus at jabber.ccc.de       | IRC: hircus at irc.freenode.net

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/


More information about the vbox-dev mailing list