Core merge and Package Guidelines

[Hans de Goede]

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