[Bug 168339] Review Request: libbinio
bugzilla at redhat.com
bugzilla at redhat.com
Fri Sep 16 02:33:20 UTC 2005
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
------- 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
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.
More information about the fedora-extras-list