Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: aplus-fsf - Advanced APL Interpreter https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174021 ------- Additional Comments From [EMAIL PROTECTED] 2006-07-19 19:03 EST ------- (In reply to comment #20) > (In reply to comment #19) > > That is a bug, your package should _not_ own a system directory that > > is part of the X Window System. > > Here's a list of all packages in FC5 which own that directory: > > xscreensaver-base > xorg-x11-resutils > xorg-x11-server-utils > xorg-x11-utils > xorg-x11-xsm > xorg-x11-apps > xorg-x11-xdm > > Mike, if you think these are buggy, I'll happily file bugs against them. I fixed all the xorg-x11 packages, but please file one against xscreensaver. I looked at the spec file and it's list is autogenerated, so I'd rather if the package owner resolved that one... > Honestly, I think it's reasonable to see that list and conclude that it's > expected behavior for a package that adds an app-defaults file to own > /usr/share/X11/app-defaults. Technically, it wasn't a problem previously. In fact, it was considered by many people to be a sensible thing to do, at least in certain specific circumstances. However other people believe it is very wrong and never appropriate, and so it was made into official Fedora policy which we must now adhere to religiously. ;o) For Fedora Core at least, any case which would be a special exception to this rule, generally should have the "filesystem" package own the given directory to avoid issues. For packages outside of Core, the problem still exists and nobody claims to have an adequate solution. I believe it is considered to be a minor issue that people are expected to just live with, if they uninstall a group of packages all at once and there is no package which can be deemed to be the canonical owner of a directory. Some examples might be: - povray data files - video games which provide data files which can be shared by multiple games packaged by different people, which there's no really good way to choose an owner for the dir (ie: DOOM .wad files), and the other games which use the data, do not have a real dependency on the game (DOOM), nor any particular set of data files. - any other non-FHS type of data file which does not have a standardized location in the filesystem hierarchy. But for things that do have a canonical owner which can easily be determined, such as libXt in this case, the current Fedora policy makes sense. > Jochen, do you think it would be reasonable to back out of this mess by just > adding a dependency on xterm? No. With the latest libXt package, there is no problem anymore. If your package contains an app-defaults file, then it must also have software which links to libXm, libXaw, or libXt directly, the first two of which are linked also to libXt. As such, all software either directly or indirectly already depends on libXt, and one way or another, rpm will automatically pick up the proper library dependencies without needing to specify them. This will ensure that libXt is guaranteed to be installed either prior to these packages, or as part of the same transaction which installs these packages, thus guaranteeing that the app-defaults dir has a legitimate and canonical owner (libXt). Of course this only applies to current rawhide, not FC5, however it will get fixed in FC5 when we release 7.1 for FC5 also. > That's what the app-defaults file is for, isn't it? They are X resources for Xt apps. > In FC6, the xterm dependency will pull in libXt which will own this > directory; in FC5 the directory will still be unowned in the dependency tree > but > at least that's not a bug in this package. Correct. Will be fixed in future FC5 update, so IMHO at least, 3rd party packagers should not own the dir, and shouldn't worry about it now. Thanks again for bringing up these issues. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
