[Bug 168339] Review Request: libbinio

Ralf Corsepius rc040203 at freenet.de
Sat Sep 17 05:38:00 UTC 2005


On Fri, 2005-09-16 at 10:30 -0500, Tom 'spot' Callaway wrote:
> On Fri, 2005-09-16 at 12:50 +0200, Ralf Corsepius wrote:
> > On Fri, 2005-09-16 at 06:33 -0400, bugzilla at redhat.com wrote:
> > 
> > > ------- Additional Comments From triad at df.lth.se  2005-09-16 06:33 EST -------
> > > OK so how are these disputes normally resolved?
> > > 
> > > I have no problem with doing what Ralf says, because the package that
> > > I am creating to use libbinio do not complain about having its headers
> > > in /include/binio so that is OK with me.
> > 
> > > Ralf says he will veto against this package unless I do so, so Ville,
> > Not quite, I said, I will not approve _any_ package which installs its
> > headers to /usr/include and that I am _considering_ to veto against this
> > package.
> 
> Right now, it is not a MUST that header files live in
> %{_includedir}/%{name}.
Exactly.

I am aware about this and I don't see any reason to change anything
about it, because there can be reasons why a package can't avoid
installing headers to %{_includedir}.

But I don't think it is reasonable to allow arbitrary (unimportant)
add-on packages to install their headers to %{_includedir}, without
special reasons.

That's why I initially said "I recommend installing to
%{_includedir}%{name}".

>  Technically, its not even a SHOULD. 
True.

> I'd tend to agree with Ralf on the idea, as header names are often
> extremely generic. I'd prefer that upstream make this move, but I don't
> want to discourage a packager from using their own best judgement.
>
> Basically, as the policies stand right now, since this is not a
> requirement, choosing whether or not to store headers in
> %{_includedir}/%{name} is up to the packager's discretion.
Also true, nevertheless it's my personal freedom not to formally review
and approve packages which do not meet my "personal standards" and
wanting to veto against packages which I think might have harmful long
effects.

With regard to installing headers to %{_includedir}, I don't have a
problem in packages installing a single or very few headers with
probably unique names to %{_includedir}, but I have a problem with
packages which install many headers or headers with names which are
likely to collide with official or de-facto standards to %_includedir.

Wrt. this, libbinio is a corner case:
/usr/include/binfile.h
/usr/include/binio.h
/usr/include/binstr.h
/usr/include/binwrap.h

* 4 headers, not necessarily few, but also not "many".
* The file names, at least to me seem to be very hot candidates for very
likely future clashes.

> However, I highly suggest that you contact upstream, and suggest
> (possibly with patch at the ready) that they make such a configuration
> the default.

Ralf





More information about the fedora-extras-list mailing list