[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Core merge and Package Guidelines



Michael Schwendt wrote:
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?


/usr/share/aclocal is only needed on systems with a devel environment installed so putting it in filesystem is not an option. I'm also not a fan of making packageXXX-devel require automake, because:
1) Not everyone likes autoxxx tools. I've seen and created plenty of
   packages without autoxxx. These packages usually do use foo-config or
   pkg-config in the makefile's as pkg-config and foo-config are just
   very handy. Actually when you've got them, there is less need for
   autoxxx.
2) automake puls in lots of other deps

However I'm also not a fan of having multiple packages own /usr/share/aclocal

So yes this is a problem indeed. I'm tending towards a automake-filesystem subpackage which owns /usr/share/aclocal and then packages who drop files there can use either:
Requires: automake-filesystem (prefered as file based deps make yum slow)
or:
Requires: /usr/share/aclocal

Regards,

Hans




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]