You are not logged in.

#1 2004-12-09 15:04:29

neok
Member
From: Cyprus
Registered: 2003-12-14
Posts: 190
Website

Packages hard-coded to install in /user/local

Hi,

Tried to install a package (hamlib) which is needed as a dependency of another package (gmfsk) but configure of gmfsk could not find the libs installed by hamlib because they were installed in /user/local/lib. Tried to configure hamlib with --prefix=/usr but gave me an error message saying it can only install in paths ending with /usr/local/lib.

How could I best handle this problem?

Thanks in advance!


Regards

Neoklis ... Ham Radio Call: 5B4AZ

Offline

#2 2004-12-09 16:32:23

phrakture
Arch Overlord
From: behind you
Registered: 2003-10-29
Posts: 7,879
Website

Re: Packages hard-coded to install in /user/local

contact the maintainer - search for the package on archlinux.org and email them, or possibly file a bug in the bug tracker

Offline

#3 2004-12-09 16:34:56

sarah31
Member
From: Middle of Canada
Registered: 2002-08-20
Posts: 2,975
Website

Re: Packages hard-coded to install in /user/local

if this is a package that you built then you will probably have to lok at the source/makefiles for the part that hard codes it to go to /usr/local and patch that. if not do what  phrakture said.


AKA uknowme

I am not your friend

Offline

#4 2004-12-09 18:37:44

neok
Member
From: Cyprus
Registered: 2003-12-14
Posts: 190
Website

Re: Packages hard-coded to install in /user/local

sarah31 wrote:

if this is a package that you built then you will probably have to lok at the source/makefiles for the part that hard codes it to go to /usr/local and patch that. if not do what  phrakture said.

Actually, the packages are not in Arch, I was trying to install them from downloaded sources. I will try modifying the source to fix the problem.

Thanks!


Regards

Neoklis ... Ham Radio Call: 5B4AZ

Offline

#5 2004-12-09 18:47:59

i3839
Member
Registered: 2004-02-04
Posts: 1,185

Re: Packages hard-coded to install in /user/local

It's not a bad idea to keep all custom packeg in more or less one place, like /usr/local. That avoids conflicts later with official packages and you can be sure that you don't accidentally mess up other files.

As for one package not finding the libs of another custom package:

Make sure you have "/usr/local/lib" in /etc/ld.so.conf and that you run ldconfig after installing new libs.

Offline

#6 2004-12-09 19:09:05

neok
Member
From: Cyprus
Registered: 2003-12-14
Posts: 190
Website

Re: Packages hard-coded to install in /user/local

i3839 wrote:

It's not a bad idea to keep all custom packeg in more or less one place, like /usr/local. That avoids conflicts later with official packages and you can be sure that you don't accidentally mess up other files.

As for one package not finding the libs of another custom package:

Make sure you have "/usr/local/lib" in /etc/ld.so.conf and that you run ldconfig after installing new libs.

Yes, I think I will adopt this idea, surely easier than trying to modify source/makefiles! I have some ham radio programs that I have written, installed in /usr/local/bin, and I prefer to have other similar apps in the same place.

Thanks!


Regards

Neoklis ... Ham Radio Call: 5B4AZ

Offline

#7 2004-12-09 19:27:18

Dusty
Schwag Merchant
From: Medicine Hat, Alberta, Canada
Registered: 2004-01-18
Posts: 5,986
Website

Re: Packages hard-coded to install in /user/local

i3839 wrote:

It's not a bad idea to keep all custom packeg in more or less one place, like /usr/local. That avoids conflicts later with official packages and you can be sure that you don't accidentally mess up other files.

I disagree. If you're using pacman (ie: ABS/makepkg/PKGBUILDs) to manage your system, there's no reason not to put your custom packages in standard directories. Further, if you have a useful PKGBUILD, people will eventually ask you to distribute it, and it should definately not install to /usr/local in that case.

As for avoiding conflicts with official packages, I cannot imagine very many cases where you would install a custom program that can be replaced by an official one. Either you install the official one, or you don't like the official one and choose to make your own; you wouldn't likely have them both installed, no?

I personally use /usr/local only for stuff outside of pacman control. Custom PKGBUILDs install to /usr or /opt, and custom packages that don't play nice with PKGBUILDs (like interactive binary installers, sometimes) go in /usr/local.

neok: in your case, I would install the package to /usr/local for now, to try to get it working, and to get the package that depends on it working. But later, when I had time, I would figure out how to patch the sources or makefile or configure script to install to any location. When I had done this, I would send patches to the program's developer to make it more useful for other people that want to install it, and would contribute the PKGBUILD to AUR, which you can't do yet anyway. I love hypothetical situations.

Dusty

Offline

#8 2004-12-09 19:50:09

sarah31
Member
From: Middle of Canada
Registered: 2002-08-20
Posts: 2,975
Website

Re: Packages hard-coded to install in /user/local

Bob Finch was or is a TUR and he used to maintain a large number of ham radio packages you may want to look at his TUR or try and contact him for advice suggestions.


AKA uknowme

I am not your friend

Offline

#9 2004-12-09 19:54:30

i3839
Member
Registered: 2004-02-04
Posts: 1,185

Re: Packages hard-coded to install in /user/local

Yes, sorry, badly formulated by me.

If you really made a custom Arch package which is handled by Pacman then using /usr/local is indeed wrong.

Above I meant with "custom packages" packages build with "./configure && make && make install". I shouldn't have used the term "package" in this context, but "programs", "software" or something similar instead. I didn't thought about custom pkgbuilds as I never make them (wouldn't know what to do with them).

To repeat the important part of my previous post:

Make sure you have "/usr/local/lib" in /etc/ld.so.conf and that you run ldconfig after installing new libs.

That's the reason the compile fails I guess, if you havet hat fixed up it shouldn't matter where the things are installed, except if the makefile(s) are really that stupid to hardcode the library path (which is rare).

Offline

#10 2004-12-09 21:09:47

neok
Member
From: Cyprus
Registered: 2003-12-14
Posts: 190
Website

Re: Packages hard-coded to install in /user/local

sarah31 wrote:

Bob Finch was or is a TUR and he used to maintain a large number of ham radio packages you may want to look at his TUR or try and contact him for advice suggestions.

Thanks! I found via google that Bob has made an effort to package hamlib for Arch. Its getting rather late here so tomorrow I will see if I can install it and compile the other package (gmfsk) if its not also available as a package.


Regards

Neoklis ... Ham Radio Call: 5B4AZ

Offline

#11 2004-12-09 21:14:38

neok
Member
From: Cyprus
Registered: 2003-12-14
Posts: 190
Website

Re: Packages hard-coded to install in /user/local

i3839 wrote:

<snip> Above I meant with "custom packages" packages build with "./configure && make && make install". I shouldn't have used the term "package" in this context, but "programs", "software" or something similar instead. I didn't thought about custom pkgbuilds as I never make them (wouldn't know what to do with them).
<snip>

Yes, it is the case of "./configure && make && make install" so if I Bob Finch's packages fail me for some reason, I will install to /usr/local.


Regards

Neoklis ... Ham Radio Call: 5B4AZ

Offline

#12 2004-12-09 21:49:13

sarah31
Member
From: Middle of Canada
Registered: 2002-08-20
Posts: 2,975
Website

Re: Packages hard-coded to install in /user/local

fyi,

http://xentac.net/~tur/repos.php

that lists the repos available (bob's is bfinch) that site will also lead you to his PKGBUILDs and stuff. if you put the repo info in your pacman.conf and then resync you can just install the ham radio packages he has with pacman.


AKA uknowme

I am not your friend

Offline

Board footer

Powered by FluxBB