[Bug 168339] Review Request: libbinio

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: libbinio


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168339





------- Additional Comments From rc040203 at freenet.de  2005-09-15 22:33 EST -------
(In reply to comment #5)
> (In reply to comment #4) 
> > What is so difficult to use 
> > gcc -I/usr/include/binio .... ?!? 
>  
> Well, it wouldn't be difficult to install the libs (or eg. "gcc", or whatever) 
> into a custom path and to ask everyone to deal with it either. 
GCC already does do this automatically ;)

> See comment 3.  When done _by a packager on "IMO" basis_, it's (most likely, 
> unchecked in this particular case) completely unnecessary, bloats dependent 
> packages, possible maintenance burden, results in projects needing distro 
> specific adaptations, not what upstream intended, and unexpected in general. 
BS - All packaging is based technical requirements AND on personal views.
Also, it's packagers who package set the per-package conventions for each
package. And it's the package users who have to adopt these per-package conventions.

> I didn't say that dropping everything into /usr/include is optimal either.
> But non-transparent changes like this should not be made unilaterally by 
> packagers, but rather reported/fixed upstream (preferably fixing it with a 
> foo-config and/or a pkgconfig file) if something causes real world problems, 

Any file in /usr/include causes real problems, because any file in /usr/include
* is likely to clash with standards (POSIX etc.)
* is likely to clash with other packages (other packages shipping headers with
the same name)
* prevents parallel installation.
* /usr/include is a privileged directory (system include directory) and is
treated special by compilers (secondary include path).

> or if someone cares deeply enough about it otherwise and can convince 
> upstream. 
If something clashes, it's too late for upstream to change.

Also, the main reason, why packages install headers into /usr/include is the
developers typically installing packages into private directories or into per
package directories, but not systemwide.

I will not approve any package which installs headers directly to /usr/include.

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.