[Bug 174021] Review Request: aplus-fsf - Advanced APL Interpreter

[bugzilla at redhat.com]

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 mharris at redhat.com  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.