On Sun, 5 Oct 2008 01:05:35 +0200
Alan McKinnon wrote:

> On Sunday 05 October 2008 00:03:47 Andreas Simbuerger wrote:
> > > Installs to /usr/local/lib sounds like b0rked ebuilds.  I'd try
> > > using equery to find the ebuilds that installed "bad" files.
> > >  Then I'd look for "/usr/local" in those ebuilds and fix them.
> > >  Putting the fixed ebuilds in /usr/local/portage/..., rather than
> > > just changing /usr/portage/..., might be even better.  Lastly,
> > > I'd report the b0rked ebuilds on bugzilla.gentoo.org and would
> > > include the fixes with the reports.
> > >
> > > Looking on my system, all that /usr/local/lib is
> > > /usr/local/lib64/python2.5/site-packages/doxypy-0.3rc2-py2.5.egg-info
> > > which appears to have come from manually installing
> > > ~/Download/doxypy-0.3rc2.tar.gz, i.e. the one such file I have
> > > isn't from an ebuild at all.  Might that be what's happened to
> > > you?
> > >
> > > HTH,
> > >
> > > David
> >
> > Thanks for this idea! :D
> >
> > So portage takes /usr/local/portage before /usr/portage ?
> 
> That's pretty normal, it's so that your customizations override the
> distro default, much like dot files in ~ override whatever is in /etc/
> 
> David's comment about b0rked ebuilds is spot-on. Most packages are
> built using autotools, which defaults to --prefix=/usr/local. The
> ebuild author forgot to change it to /usr/, so you have to figure out
> what he should have done and do it yourself. I would recommend
> submitting a bug report plus patch when you solve it, and meanwhile
> keeping a correct copy of the ebuild in your local overlay.
> 
> By and large the broken ebuild works, as libs in /usr/local are still
> found on systems with sane linkers, despite the location being
> technically incorrect

FWIW, I too have dev-python/pycrypto-2.0.1-r6 installed on an AMD64
system.  However my files are in /usr/lib, not in /usr/local/lib as
reported by the OP -- which makes it sound like the ebuild is OK and
there's something unusual in his environment.

Reply via email to