Core merge and Package Guidelines

Michael Schwendt bugs.michael at gmx.net
Fri Feb 9 10:26:26 UTC 2007


On Fri, 9 Feb 2007 02:05:19 +0100, Patrice Dumas wrote:

> 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.

There has been some unfortunate development in that area.

If memory serves correctly, we have never wanted absolutely strict
ownership in those cases, at least not when we created the initial
reviewing guidelines.

It's not worth the effort. It would be wrong to create a dependency on an
optional help viewer just to get ownership of a documentation root
directory.

The bad thing, however, is that orphaned directories can be created with
insufficient file access permission bits when an administrator uses a
restrictive umask -- can anyone confirm that this is still true in 2007?
And orphaned directories are not removed during package removal.

[ Maybe I'm missing something, but during installation of packages, RPM
could maintain a list of orphaned directories and create them with the
defattr values, so a restrictive umask does not cause them to be
inaccessible by ordinary users. During package removal, it could remove
such a directory if empty and if no package in the database contains it. ]

Reviewers and packagers argue about /usr/share/aclocal/:

  $ rpm -qf /usr/share/aclocal
  file /usr/share/aclocal is not owned by any package
  
  $ ls /usr/share/aclocal | wc -l
  15

Two cases are to distinguish here:

1) A big -devel package that ships multiple libraries and headers in
versioned directories.

2) A tiny -devel package which is trivial to build with.

For case 1, not using automake macros (to find the API locations, cflags
and linker options) would be very unusual. Just like not running any
foo-config script to retrieve the same values. In that case I would
recommend a "Requires: automake". Not only to keep /usr/share/aclocal
"owned", but because other packages building with the -devel package very
likely would use automake anyway. For case 2, requiring automake just to
get ownership of a single directory would be overhead.

Unlike with pkg-config, /usr/share/aclocal is not covered by the
guidelines yet, however.

For files in pkg-config's directories, the original reviewing guidelines
have been modified to make "Requires: pkgconfig" a MUST in Sep 2006,
when .pc files are included:

http://fedoraproject.org/wiki/Packaging/ReviewGuidelines?action=diff&rev2=36&rev1=35

More important than requiring pkgconfig is to keep the .pc file dependency
chains complete as else you break pkg-config queries for all installed
files.

And there is no alternative to "Requires: automake", when files are
included in /usr/share/aclocal, because:

  MUST: Packages must not own files or directories already
  owned by other packages.

Though, it's with exceptions:

  If you feel that you have a good reason to own a file or directory
  that another package owns, then please present that at package
  review time.

http://fedoraproject.org/wiki/Packaging/ReviewGuidelines?action=diff&rev2=17&rev1=16

So, if a packager wants to include /usr/share/aclocal and be done, other
reviewers argue about whether that is correct or good and whether it
breaks "Requires: /usr/share/aclocal" or some forms of RPM queries.

How to escape from this?




More information about the Fedora-maintainers mailing list