Re: Pkgsrc on linux, defective by design ?

[Francisco Garcia <frankalahan%gmail.com@localhost>]

Am 31.05.2010 um 21:45 schrieb Ross Cameron:

> Out of total curiosity (and I know I shouldn't be asking this but
> anyhow) WHY are you trying to use PKGSRC on CentOS?
>    There is little sense to be made of that.
> 
> CentOS by choice ships older (known stable and secure) code and PKGSRC
> by comparisson (in many cases not all) ships newer releases. There are
> conflicting ideals at work here and you will have issues as a result.
> 

Do you mean that pkgsrc is not the best choice for servers where packages must 
be only updated for stability/security reasons?

I use pkgsrc because of extra control on the programs I install (compilation 
parameters)

I also find amazing to be able to do:

$ pkg_admin fetch-pkg-vulnerabilities
$ pkg_admin audit            

I would like to know if people find pkgsrc not suitable for such scenario. 
Was that one of the reasons for OpenBSD to make a fork?

So far pkgsrc is my first choice to build/control open-source software in 
Linux/Mac/Windows/BSD and I want to understand better where it fails


> You will find that PKGSRC works much more happily on something like
> Fedora 13 for example.
>    Although I find a Slackware derivative like a very minimal Slax
> the most comfortable with PKGSRC
> 
> And to add to it.... almost anything you could possibly need you will
> find in a binary form compiled for CentOS/RHEL/OracleEL in a repo.
> thats what the package manager is there for and in any case you can
> quite easily build RPMs against CentOS and host you're own repo quite
> easily.
> 
> What is it that you are trying to accomplish?
> 
> 
> 
> "Opportunity is most often missed by people because it is dressed in
> overalls and looks like work."
>    Thomas Alva Edison
>    Inventor of 1093 patents, including:
>        The light bulb, phonogram and motion pictures.
> 
> 
> 
> 
> On Wed, May 19, 2010 at 4:53 PM, Youssef Ghorbal <djo%pasteur.fr@localhost> 
> wrote:
>> Hello pkgsrc users,
>> 
>>        I'm trying to set up pkgsrc on a CentOS (5.4) and I came across some 
>> issues regarding linking against the native library VS the pkgsrc one. A 
>> typical exemple is libxml2.
>>        After some digging I found out that, no matter what happens, 
>> BUILDLINK3 framework always add -L /usr/lib64 -Wl,-R/usr/lib64 to the gcc 
>> command line option. For exemple when we try to compile 
>> converters/py-libxml2 (LibXML2 bindings for Python) the gcc line will be 
>> something like :
>> 
>>        gcc -pthread -shared -L/opt/pkg/tmp/lang/python26/work/Python-2.6.4 
>> -L/usr/lib64 -Wl,-R/usr/lib64 [....]  -L/opt/pkg/lib -lpython2.6 -o 
>> build/lib.linux-x86_64-2.6-debug/Ft/Lib/EscapeQuotesc.so
>> 
>>         The GNU ld looks for libraries in a search path specified by -L 
>> options in the order of appearence. In my case, the EscapeQuotesc.so will 
>> always be linked against the native libxml2 lib beacause of the precedence 
>> of -L/usr/lib64 in the command line.
>> 
>>        What I can't understand, is why the BUILDLINK3 framwork keeps 
>> appending a default path (/usr/lib64) while it's completely useless and 
>> leads to bogus beahaviour like the one I explained. For me a sane way of 
>> doing will be to only append pkgsrc specific paths using -L option. GNU ld 
>> looks for libs in priority in the search path specified by  -L options and 
>> will fail back to system "default" paths.
>> 
>>        Appending of -L/usr/lib64 will alwas lead to linking against native 
>> libs when they are present on the system which not always desired.
>> 
>> Youssef Ghorbal
>> 
>> PS : the /usr/lib64 is added in the pkgsrc/mk/buildlink3/bsd.buildlink3.mk 
>> file (line 350 for the creation of "lib64" based on the ABI  and line 379 
>> for the appending of /urs/lib64 to the BUILDLINK_LDFLAGS variable)