rpms/polkit-gnome/devel polkit-gnome.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2

Panu Matilainen pmatilai at laiskiainen.org
Wed Jun 10 09:25:39 UTC 2009


On Tue, 9 Jun 2009, Matthias Clasen wrote:

> On Tue, 2009-06-09 at 14:58 +0200, Christoph Wickert wrote:
>
>>>
>>> # for /usr/share/gnome/autostart
>>> Requires: gnome-session
>>
>> Great! This adds
>> gnome-session: 1.8 MB
>> control-center: 7.1 MB
>> GConf2: 5,5 MB
>> gnome-keyring: 2,3 MB
>> gnome-vfs2: 3.1 MB
>>
>> You added at least ~ 22,8 MB overhead just for directory ownership,
>> although I asked you to _not_ do this. I think users of alternative
>> desktops and the maintainers of their spins will not be amused. Last
>> week you told me, that a one advantage of the new polkit is that no
>> longer requires GConf2, but now it's dragged in again.
>>
>
> Your anger is misdirected. Complain to the rpm people for not handling
> directories in a sane way. Or better still, send them a patch...

Define sane. The unowned directory issue was hashed at quite a length in 
January [1], every option was disliked by somebody.

Short summary of the options discussed:
a) Create file dependencies for every directory not explicitly owned by 
the package at build time. Easy to do and works with everything out there 
but causes *huge* metadata bloat.

b) Calculate directory dependencies at runtime. Easy to do but either 
causes transactions to abort due to missing dependencies whenever unowned 
directories are found, or would require changing all the depsolvers to 
know about and handle the implicit directory dependencies too.

c) Have rpm silently add ownership of unowned directories to the package 
that creates them. This could cause weird directory conflicts when some 
other package actually owns the directory / becomes the owner, and just 
feels wrong anyhow.

d) Variations of a-c where it'd just warn about the unowned directories.

I've been playing with using directories for additional ordering 
information (fairly easy to do), c) is basically a one-liner patch on top 
of that.

[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg02326.html

 	- Panu -




More information about the fedora-devel-list mailing list