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