Core merge and Package Guidelines

[Patrice Dumas]

On Thu, Feb 08, 2007 at 04:02:34PM -0800, Toshio Kuratomi wrote:
> Hey all,
> 
> I'm trying to smooth out the process of getting changes and
> clarifications to the guidelines to make the Core Review process go
> quicker and easier.  Here's what I'd like to see: if a reviewer and
> packager are at an impasse WRT following or not following some aspect of
> the Guidelines, ping me to look at it.  I'll read the issue and let

I don't know if there are real impasses, but the directory owning is 
causing trouble -- and in most cases I agree there is a problematic
situation. It has also come again and again before the merge, so maybe
it won't be solved now. Solving this issue isn't necessarily only a
policy issue, since it may be worked around by changes in some packages.

The issue arise when a package installs something in a directory, but 
the package owning the directory isn't a hard requirement for the 
package. The typical example is for documentation. Many packages 
install things below
/usr/share/omf/
or
/usr/share/gtk-doc/
but they don't really require the 'natural' directory owner, which could
be here, for example, scrollkeeper or yelp and gtk-doc or devhelp.

Similar issues arise with icons, logrotate files, autoconf files. Some
case aren't as clear as documentation, for example it could be arguable
that automake (for aclocal) is required when autoconf macros are 
installed.

What are exactly the guidelines or best practices? More precisely

* when should directories be added to the filesystem package
* when should a specific filesystem package be split out
* is it right to require a application when it is mostly for dir
  ownership?

It may happen that there is no definite response, but it would be nice
if there was some agreement.

For an example, see
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222905

There are many other examples, I could retrieve them if needed.

--
Pat