Core merge and Package Guidelines

[Ralf Corsepius]

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