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
--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers
--
Fedora-maintainers-readonly mailing list
Fedora-maintainers-readonly@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
