On Fri, 2007-02-09 at 11:39 +0100, Hans de Goede wrote: > 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. But we always have wanted to have clean package removals. > > 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/: Well, this is just a popular and commonly met example for a far more general problem: plugins/drop-in-packages Examples: * *.pc and pkgconfig (Almost identical situation as with automake, default search directory, used by one application one) * "/usr/share/mozilla/plugin", way more complicated. Being used by several applications (mozilla, firefox, seamonkey etc). * dlopen'ed DSOs expected under certain paths (The same situation as mozilla-plugins, but more general) * scripting-language-modules (E.g. perl) - No strict hierarchy between modules. Unique to /usr/share/aclocal is: * /usr/share/aclocal does NOT have to be part of the automake package!! /usr/share/aclocal is the default directory aclocal looks into for *.m4 macros NOT owned by the automake package itself. * /usr/share/aclocal is only used by aclocal by no other applications (except may-be some RAD-GUI tools) * /usr/share/aclocal actually is part of the subsystem used by the application "aclocal". It is NOT part of the application "automake"! > > $ 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. Yes, but the situation of automake is too similar to pkg-config to justify this deviation. > > 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. IMNSHO, this rule is simply wrong. It's nothing else but a fallback rule, which fails in many cases. > > 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? Depends on which problem you want to solve: * Simple installation, pulling in the infrastructure a package optionally supports, rsp. brings a package into "usable shape". => This can be approached by the same approach as it is being applied by pkgconfig: Any package installing a /usr/share/aclocal/*.m4 file must require "automake". * Clean rpm-installation/package removal => One option is the same approach as it is being applied to perl-modules: "Any directory under /usr/lib/perl* which is not part of the basesystem and the base-perl package must be owned by the perl-module" > /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. I am not a fan of double standards => I am strongly opposed to implementing an automake specific rule. We need a systematic general approach. > 2) automake puls in lots of other deps This simply is not true. automake doesn't pull in a lot of deps. I only has two major dependencies: autoconf and perl. All the rest is a standard POSIX/GNU devel environment a developer will have installed in any case. > 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) Well, IMO, the latter is a design flaw in yum, but this would be a different topic. > or: > Requires: /usr/share/aclocal This will break "Joe Random Developer"'s request for "simple installation", and will cause rpm issues (To be verified if they still are present). Ralf -- 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
