10 Aug
2005
10 Aug
'05
9:16 a.m.
I'd come down there and sweep the floors
That's my job! I also clean the crt screens and recycle the
water bottles.
10 Aug
10 Aug
1:13 p.m.
On Wed, 2005-08-10 at 04:16 -0700, Bill Schottstaedt wrote:
Dang! Just when I thought I'd found my niche...
But back to this library question...
I wrote:
I'd come
down there and sweep the floors
That's my job! I also clean the crt screens and recycle the
water bottles.
**It then complained about libgnomeui. When I
./configure that one I
get:
checking for libgnome-2.0 >= 2.0.0 libgnomecanvas-2.0 >= 2.0.0
libbonoboui-2.0 >= 2.0.0 gconf-2.0 >= 1.1.11... Package libgnome-2.0
was
not found in the pkg-config search path.
Perhaps you should add the directory containing `libgnome-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libgnome-2.0' found
It seems like my dependency problems are because the various package
metadata (.pc) files don't exist. After getting the source and
rebuilding them (libsndfile and fftw), the .pc files were now in place
(/usr/local/lib/pkgconfig) and the gwc build successfully got past those
points.
So, why do I not have the .pc metadata files in my FC3 even though the
actual library files were there (in /usr/lib) all along? Is this what
Fernando is talking about when
Fernando Lopez-Lezcano wrote:
I did not follow the whole thread, but... most
probably there is
nothing
"missing" as gnome is installed and all libraries are there
(probably).
You may not be aware that most packages that deal with libraries that
can be used for development are split into two packages, the "normal"
one has all the libraries that programs that were built with this
dependency need to run, and then another package usually named
"xxx-devel" that has the stuff you need to actually _build_ packages
that need that particular library. If you are missing something try to
install NAME_OF_MISSING_LIBRARY-devel (if you find the "base" package,
of course, otherwise you will need both).
This reminds me that when I installed FC3 from CCRMA, I choose NOT to
install any of the "Development" packages like:
"Development Tools"
"X Software Development"
"Gnome Software Development"
etc
Would installing these have prevented these dependency problems?
I thought I'd try to go back and add them from the FC3 CDs but when I
check them and say "go" I get a "Packages Not Found" error pop-up
saying
installation cannot continue because a bunch of packages could not be
found like netpbm, xorg-x11-libs, glib2, pygtk2, gtk2. So now I can't
even add packages from the original FC3 CDs I installed from. 8^(
help.... 8^)
Mike
Mike Jewell
One-Up Audio
5:16 p.m.
On Wed, 2005-08-10 at 08:13, Mike Jewell wrote:
But back to this library question...
I wrote:
Hmmm, that may have solved the problem right now but it is not good in
the long term. You just installed a second copy of, for example,
libsndfile, in a different place in your filesystem (/usr/local instead
of /usr as installed by the rpm).
You should have installed the development packages:
apt-get install libsndfile-devel fftw3-devel
They are part of the Planet CCRMA repository.
This may not be a problem now but it will/can when packages are upgraded
in Planet CCRMA and become out of sync with the development files you
have.
**It then complained about libgnomeui. When I
./configure that one I
get:
checking for libgnome-2.0 >= 2.0.0 libgnomecanvas-2.0 >= 2.0.0
libbonoboui-2.0 >= 2.0.0 gconf-2.0 >= 1.1.11... Package libgnome-2.0
was
not found in the pkg-config search path.
Perhaps you should add the directory containing `libgnome-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libgnome-2.0' found
It seems like my dependency problems are because the various package
metadata (.pc) files don't exist. After getting the source and
rebuilding them (libsndfile and fftw), the .pc files were now in place
(/usr/local/lib/pkgconfig) and the gwc build successfully got past those
points. So, why do I not have the .pc metadata files in my FC3
even though the
actual library files were there (in /usr/lib) all along? Is this what
Fernando is talking about when
Fernando Lopez-Lezcano wrote:
> I did not follow the whole thread, but... most probably there is
> nothing
> "missing" as gnome is installed and all libraries are there
> (probably).
> You may not be aware that most packages that deal with libraries that
> can be used for development are split into two packages, the "normal"
> one has all the libraries that programs that were built with this
> dependency need to run, and then another package usually named
> "xxx-devel" that has the stuff you need to actually _build_ packages
> that need that particular library. If you are missing something try to
> install NAME_OF_MISSING_LIBRARY-devel (if you find the "base" package,
> of course, otherwise you will need both).
Yup...
This reminds me that when I installed FC3 from CCRMA,
I choose NOT to
install any of the "Development" packages like:
"Development Tools"
"X Software Development"
"Gnome Software Development"
etc
Would installing these have prevented these dependency problems?
It depends on what you want to compile.
I thought I'd try to go back and add them from the
FC3 CDs but when I
check them and say "go" I get a "Packages Not Found" error pop-up
saying
installation cannot continue because a bunch of packages could not be
found like netpbm, xorg-x11-libs, glib2, pygtk2, gtk2. So now I can't
even add packages from the original FC3 CDs I installed from. 8^(
Using which program? The "Add/Remove Applications" in the Fedora menu?
Did you install from the original Fedora cdroms? That should work, I
guess.
help.... 8^)
If you have the standard URL's in your apt sources.list configuration
file all those packages should be installable through apt-get.
If you want to compile something and it complains about software being
missing, for example, glib2, then see if you have the development
package installed:
rpm -q glib2-devel
if not then try to install it:
apt-get install glib2-devel
-- Fernando
11 Aug
11 Aug
12:42 p.m.
On Wed, 2005-08-10 at 12:16 -0700, Fernando Lopez-Lezcano wrote:
It seems like my dependency problems are
because the various package
metadata (.pc) files don't exist. After getting the source and
rebuilding them (libsndfile and fftw), the .pc files were now in place
(/usr/local/lib/pkgconfig) and the gwc build successfully got past those
points.
Hmmm, that may have solved the problem right now but it is not good in
the long term. You just installed a second copy of, for example,
libsndfile, in a different place in your filesystem (/usr/local instead
of /usr as installed by the rpm).
Yes. I thought that seemed odd. Thanks for verifying.
***What's the correct way to un-install them now?***
OK. It's starting to make sense.
No. I just put in the original FC3 CD #1 I downloaded from CCRMA and
originally installed on my machine and ran autorun to get the "Add or
Remove Packages" window which, after picking "Forward" a couple of times
and picking the "Gnome Software Development" package, for instance,
produced the "Packages Not Found" error.
You should have installed the development packages:
apt-get install libsndfile-devel fftw3-devel
They are part of the Planet CCRMA repository.
This may not be a problem now but it will/can when packages are upgraded
in Planet CCRMA and become out of sync with the development files you
have.
Makes sense.
So, why do I not have the .pc metadata files in
my FC3 even though the
actual library files were there (in /usr/lib) all along? Is this what
Fernando is talking about when
Fernando Lopez-Lezcano wrote:
> I did not follow the whole thread, but... most probably there is
> nothing
> "missing" as gnome is installed and all libraries are there
> (probably).
> You may not be aware that most packages that deal with libraries that
> can be used for development are split into two packages, the "normal"
> one has all the libraries that programs that were built with this
> dependency need to run, and then another package usually named
> "xxx-devel" that has the stuff you need to actually _build_ packages
> that need that particular library. If you are missing something try to
> install NAME_OF_MISSING_LIBRARY-devel (if you find the "base" package,
> of course, otherwise you will need both).
Yup...
This reminds
me that when I installed FC3 from CCRMA, I choose NOT to
install any of the "Development" packages like:
"Development Tools"
"X Software Development"
"Gnome Software Development"
etc
Would installing these have prevented these dependency problems?
It depends on what you want to compile.
I thought I'd try to go back and add them
from the FC3 CDs but when I
check them and say "go" I get a "Packages Not Found" error pop-up
saying
installation cannot continue because a bunch of packages could not be
found like netpbm, xorg-x11-libs, glib2, pygtk2, gtk2. So now I can't
even add packages from the original FC3 CDs I installed from. 8^(
Using which program? The "Add/Remove Applications" in the Fedora menu?
Did you install from the original Fedora cdroms? That should work, I
guess. If you have the standard URL's in your apt
sources.list configuration
file all those packages should be installable through apt-get.
If you want to compile something and it complains about software being
missing, for example, glib2, then see if you have the development
package installed:
rpm -q glib2-devel
if not then try to install it:
apt-get install glib2-devel
-- Fernando
I'll take another look at it using your suggestions.
Thanks again.
Mike
Mike Jewell
One-Up Audio
1:07 p.m.
Yes. I thought that seemed odd. Thanks for
verifying.
***What's the correct way to un-install them now?***
go back into the source code directory you built+installed them from.
type:
make uninstall
you must not have re-run configure with different options since doing
the last make install.
note that in the case of the ultimate screw up (e.g. with JACK), you can
still use this method. suppose you mistakenly did this:
(unpack source tarball)
cd srcdir
./configure
make
make install
(remember that you mean to use --prefix=/usr)
./configure --prefix=/usr
make
make install
(remember that you shouldn't mix tarballs and packages)
looks bad now - you have two versions of the software, one under /usr,
one under /usr/local.
its ok, just do this:
cd srcdir
./configure
make uninstall
./configure --prefix
make uninstall
and its all cleaned up.
--p "no sir, never had to do that, no sir, never, no sir"
14 Aug
14 Aug
10:48 p.m.
On 8/12/05, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
An advice I would add: do not install libraries from source code by
yourself (ie without your package manager knowing it), because it will
cause many problems later, if you do not know exactly what you are
doing.
If you really want to try some new versions from source, you should
use something like checkinstall, which builds a rpm or a .deb from
your sources.
http://asic-linux.com.mx/~izto/checkinstall/
The big advantage of this method is that your package manager knows
about what you installed, and where, thus making the uninstall part a
non problem.
Yes. I thought that seemed odd. Thanks for
verifying.
***What's the correct way to un-install them now?***
go back into the source code directory you built+installed them from.
type:
make uninstall
you must not have re-run configure with different options since doing
the last make install.
note that in the case of the ultimate screw up (e.g. with JACK), you can
still use this method. suppose you mistakenly did this:
(unpack source tarball)
cd srcdir
./configure
make
make install
(remember that you mean to use --prefix=/usr)
./configure --prefix=/usr
make
make install
(remember that you shouldn't mix tarballs and packages)
looks bad now - you have two versions of the software, one under /usr,
one under /usr/local.
its ok, just do this:
cd srcdir
./configure
make uninstall
./configure --prefix
make uninstall
and its all cleaned up.
--p "no sir, never had to do that, no sir, never, no sir" 
15 Aug
15 Aug
7:37 a.m.
David Cournapeau wrote:
On 8/12/05, Paul Davis
<paul(a)linuxaudiosystems.com> wrote:
An advice I would add: do not install libraries from source code by
yourself (ie without your package manager knowing it), because it will
cause many problems later, if you do not know exactly what you are
doing.
If you really want to try some new versions from source, you should
use something like checkinstall, which builds a rpm or a .deb from
your sources.
http://asic-linux.com.mx/~izto/checkinstall/
The big advantage of this method is that your package manager knows
about what you installed, and where, thus making the uninstall part a
non problem.
Hi Now thats a nice link!
Bob
Yes. I
thought that seemed odd. Thanks for verifying.
***What's the correct way to un-install them now?***
go back into the source code directory you built+installed them from.
type:
make uninstall
you must not have re-run configure with different options since doing
the last make install.
note that in the case of the ultimate screw up (e.g. with JACK), you can
still use this method. suppose you mistakenly did this:
(unpack source tarball)
cd srcdir
./configure
make
make install
(remember that you mean to use --prefix=/usr)
./configure --prefix=/usr
make
make install
(remember that you shouldn't mix tarballs and packages)
looks bad now - you have two versions of the software, one under /usr,
one under /usr/local.
its ok, just do this:
cd srcdir
./configure
make uninstall
./configure --prefix
make uninstall
and its all cleaned up.
--p "no sir, never had to do that, no sir, never, no sir" 
12:13 p.m.
David Cournapeau wrote:
On 8/12/05, Paul Davis
<paul(a)linuxaudiosystems.com> wrote:
An advice I would add: do not install libraries from source code by
yourself (ie without your package manager knowing it), because it will
cause many problems later, if you do not know exactly what you are
doing.
If you really want to try some new versions from source, you should
use something like checkinstall, which builds a rpm or a .deb from
your sources.
http://asic-linux.com.mx/~izto/checkinstall/
The big advantage of this method is that your package manager knows
about what you installed, and where, thus making the uninstall part a
non problem.
the other option is to install into /opt/package-version (using
./configure --prefix=/opt/package-version), possibly using stow to
create links in /usr/local, in that case the instwallation is completely
independent from your packaging system, you can have multiple versions
installed and control which one is used by either stow or using env
variables etc.
(one way or another definitely do not install anything into usualy
system libs like /usr, /etc etc., pretty much everything except of
/usr/local, /opt and /home should be handled by package manager)
erik
Yes. I
thought that seemed odd. Thanks for verifying.
***What's the correct way to un-install them now?***
go back into the source code directory you built+installed them from.
type:
make uninstall
you must not have re-run configure with different options since doing
the last make install.
note that in the case of the ultimate screw up (e.g. with JACK), you can
still use this method. suppose you mistakenly did this:
(unpack source tarball)
cd srcdir
./configure
make
make install
(remember that you mean to use --prefix=/usr)
./configure --prefix=/usr
make
make install
(remember that you shouldn't mix tarballs and packages)
looks bad now - you have two versions of the software, one under /usr,
one under /usr/local.
its ok, just do this:
cd srcdir
./configure
make uninstall
./configure --prefix
make uninstall
and its all cleaned up.
--p "no sir, never had to do that, no sir, never, no sir"
2:04 p.m.
On Mon, 2005-08-15 at 07:13 -0700, Erik Steffl wrote:
David Cournapeau wrote:
I like this idea of containing it in it's own little world so you can
have different versions installed for testing, etc. But why would you
want links in /usr/local? Wouldn't the --prefix set it all up to run
from the /opt dir?
And what is stow? I don't seem to have that on my CCRMA FC3 distro.
Thanks for the good pointers.
Mike
Mike Jewell
One-Up Audio
On 8/12/05, Paul Davis
<paul(a)linuxaudiosystems.com> wrote:
An advice I would add: do not install libraries from source code by
yourself (ie without your package manager knowing it), because it will
cause many problems later, if you do not know exactly what you are
doing.
If you really want to try some new versions from source, you should
use something like checkinstall, which builds a rpm or a .deb from
your sources.
http://asic-linux.com.mx/~izto/checkinstall/
The big advantage of this method is that your package manager knows
about what you installed, and where, thus making the uninstall part a
non problem.
the other option is to install into /opt/package-version (using
./configure --prefix=/opt/package-version), possibly using stow to
create links in /usr/local, in that case the instwallation is completely
independent from your packaging system, you can have multiple versions
installed and control which one is used by either stow or using env
variables etc. Yes. I
thought that seemed odd. Thanks for verifying.
***What's the correct way to un-install them now?***
go back into the source code directory you built+installed them from.
type:
make uninstall
you must not have re-run configure with different options since doing
the last make install.
note that in the case of the ultimate screw up (e.g. with JACK), you can
still use this method. suppose you mistakenly did this:
(unpack source tarball)
cd srcdir
./configure
make
make install
(remember that you mean to use --prefix=/usr)
./configure --prefix=/usr
make
make install
(remember that you shouldn't mix tarballs and packages)
looks bad now - you have two versions of the software, one under /usr,
one under /usr/local.
its ok, just do this:
cd srcdir
./configure
make uninstall
./configure --prefix
make uninstall
and its all cleaned up.
--p "no sir, never had to do that, no sir, never, no sir"
10:14 p.m.
Mike Jewell wrote:
On Mon, 2005-08-15 at 07:13 -0700, Erik Steffl wrote:
well, imagine you have number of programs installed this way, to
access them in easy way you'd have to make sure that they are all in
your path, that the shared libs are found by linker, the include files
by c/c++ compilers etc.
here's where you'd use stow - each well behave package has directory
structure like the unix root (with bin, etc, lib and other directories),
stow creates links so that the whole package is in /usr/local/bin, example:
/opt/something-1.0/bin/program
/opt/something-1.0/bin/anotherProgram
/opt/something-1.0/lib/libsome.so
/opt/something-1.0/doc/something/README.txt
stow will create following links:
/usr/local/bin/program -> /opt/something-1.0/bin/program
/usr/local/bin/anotherProgram -> /opt/something-1.0/bin/anotherProgram
/usr/local/lib/libsome.so -> /opt/something-1.0/lib/libsome.so
/usr/local/doc/something/README.txt ->
/opt/something-1.0/doc/something/README.txt
that way you can just add /use/local/bin to you path (and other libs
as well), you kinda have the extra stuff inciorporated into your system
but at same time you know exactly which file is from which package, you
can use stow to remove the packages etc. So if you want to upgrade to
something 1.1 you just install it into /opt/something-1.1 and use stow
to remove something-1.0 links and create something-1.1 links
I usually don't bother but e.g. I was working at a place where I
didn't have access to root, I wasn't able to install packages so I
installed some software into ~/opt and used stow to create links in
~/local, set up my path and linker search path etc. and it worked very well
e.g. now (at work) I only have few non-essential extra packages (like
mplayer, bashish, x11vnc) so I don't even use stow...
erik
David Cournapeau wrote:
I like this idea of containing it in it's own little world so you can
have different versions installed for testing, etc. But why would you
want links in /usr/local? Wouldn't the --prefix set it all up to run
from the /opt dir?
And what is stow? I don't seem to have that on my CCRMA FC3 distro. On 8/12/05, Paul Davis
<paul(a)linuxaudiosystems.com> wrote:
the other option is to install into /opt/package-version (using
./configure --prefix=/opt/package-version), possibly using stow to
create links in /usr/local, in that case the instwallation is completely
independent from your packaging system, you can have multiple versions
installed and control which one is used by either stow or using env
variables etc. >Yes. I thought that seemed odd. Thanks for
verifying.
>***What's the correct way to un-install them now?***
go back into the source code directory you built+installed them from.
type:
make uninstall
you must not have re-run configure with different options since doing
the last make install.
note that in the case of the ultimate screw up (e.g. with JACK), you can
still use this method. suppose you mistakenly did this:
(unpack source tarball)
cd srcdir
./configure
make
make install
(remember that you mean to use --prefix=/usr)
./configure --prefix=/usr
make
make install
(remember that you shouldn't mix tarballs and packages)
looks bad now - you have two versions of the software, one under /usr,
one under /usr/local.
its ok, just do this:
cd srcdir
./configure
make uninstall
./configure --prefix
make uninstall
and its all cleaned up.
--p "no sir, never had to do that, no sir, never, no sir"
An advice I would add: do not install libraries from source code by
yourself (ie without your package manager knowing it), because it will
cause many problems later, if you do not know exactly what you are
doing.
If you really want to try some new versions from source, you should
use something like checkinstall, which builds a rpm or a .deb from
your sources.
http://asic-linux.com.mx/~izto/checkinstall/
The big advantage of this method is that your package manager knows
about what you installed, and where, thus making the uninstall part a
non problem. 
16 Aug
16 Aug
2:05 a.m.
I use FC3 with the planet ccrma on top of it. I try to keep the machine as clean as I
can(good way to test the Fernando's newest builds). But when I see the
newest/greatest program anounced I have a hard time not wanting to check it out and build
it on the machine.
A while back I started using my own little directory structure to build within; both to
see if a program will build within the planet environment, and to check out a new program
to see if I like it.
The way I do it is to let the normal linux file permissions keep the new builds from
installing over the main system by doing the the configure-make-make install as a regular
user.
I just make a directory under my home directory(or other user if I'm really nervous
about the program I'm about to check out), and do everything there. This is the
setup I've been using, which seems to work for quite a few programs:
I make a directory called /home/tracey/newbuilds/ where I uncompress and untar the program
I need to build and check out. I also have /home/tracey/newbuilds/usr/ there with the
subdirectories bin, lib, local, share, and man off of that.
I then just pop into the directory where the new program is untared to and do:
./configure --help
to see if there are any program other switches I may want to use
and then do
./configure --prefix=/home/tracey/newbuilds/usr
make
make install
Most of the time the program can be run using the long path name:
/home/tracey/newbuilds/usr/bin/newprogram
and the man pages can be read by using
man -M /home/tracey/newbuilds/usr/man/newprogram
9:59 a.m.
On 8/16/05, Tracey Hytry <shakti(a)bayarea.net> wrote:
I use FC3 with the planet ccrma on top of it. I try
to keep the machine as clean as I can(good way to test the Fernando's newest builds).
But when I see the newest/greatest program anounced I have a hard time not wanting to
check it out and build it on the machine.
Well, this approach, as installing in /opt (or whatever directory
without the package manager to know), is really error prone on the mid
term, I think. For on or two programs, this works ok. But still, you
have no ways to remove software this way, most of the time, because
you have no information on what files and modifications to the system
was done by the software you've installed (except if an uninstall
target was done in the source of the programs).
And then comes the problem of libraries. In that case, it quickly
become a big mess if you do not know exactly what you are doing. Let's
say for example you installed a library from source, and then it
become available for your package manager: you still may use the
version installed from source, wihtout you knowing it, and it may
cause some random crash because of some version differences.
Basically, installing from sources without the help of the package
manager is ok if nothing depends on what you are installing. It
quickly become unmanageable if other softwares depend on it. I found
checkinstall much more robust.
10:29 a.m.
David Cournapeau wrote:
Well, this approach, as installing in /opt (or
whatever directory
without the package manager to know).....
I guess I need to learn how to write a little better? What I ment to say in my post was
that I do it this way to check out if something will indeed run and if it's worth the
trouble to get RPM'd.
Maybe I'm a little naive, but I thought that since I do the whole process as a
local(non-root) user, that I can't write to most of /usr? Maybe I need to study up on
what file permissions mean; because I really thought that since most of it is marked
"-rwxr-xr-x 1 root root" when I do a directory listing, that I couldn't
write over these areas.
Thanks for enlightening me.
(and as far as adding libraries from source without using the package manager - been
there, done that, already know the pitfalls... that's why I try to keep a clean
system:)
Tracey.
4:40 p.m.
Tracey Hytry wrote:
David Cournapeau wrote:
you were right in the first place:-) It is good practice to run
installs as non-root since you're pretty sure it's not going to ruin
your system.
Well, this approach, as installing in /opt (or
whatever directory
without the package manager to know).....
I guess I need to learn how to write a little better? What I ment to
say in my post was that I do it this way to check out if something
will indeed run and if it's worth the trouble to get RPM'd.
Maybe I'm a little naive, but I thought that since I do the whole
process as a local(non-root) user, that I can't write to most of
/usr? Maybe I need to study up on what file permissions mean;
because I really thought that since most of it is marked "-rwxr-xr-x
1 root root" when I do a directory listing, that I couldn't write
over these areas.
Thanks for enlightening me. (and as far as adding libraries from source without
using the package
manager - been there, done that, already know the pitfalls... that's
why I try to keep a clean system:)
:-)
erik
4:39 p.m.
David Cournapeau wrote:
On 8/16/05, Tracey Hytry <shakti(a)bayarea.net>
wrote:
? essentially I agree but why would uninstalling a program that was
installed into ONE directory under /opt be a problem? There were
obviously NO modifications to the system outside of that directory (I
usually make sure of it by not installing as root)
I use FC3 with the planet ccrma on top of it. I
try to keep the machine as clean as I can(good way to test the Fernando's newest
builds). But when I see the newest/greatest program anounced I have a hard time not
wanting to check it out and build it on the machine.
Well, this approach, as installing in /opt (or whatever directory
without the package manager to know), is really error prone on the mid
term, I think. For on or two programs, this works ok. But still, you
have no ways to remove software this way, most of the time, because
you have no information on what files and modifications to the system
was done by the software you've installed (except if an uninstall
target was done in the source of the programs). And then comes the problem of libraries. In that case,
it quickly
become a big mess if you do not know exactly what you are doing. Let's
say for example you installed a library from source, and then it
become available for your package manager: you still may use the
version installed from source, wihtout you knowing it, and it may
cause some random crash because of some version differences.
Basically, installing from sources without the help of the package
manager is ok if nothing depends on what you are installing. It
quickly become unmanageable if other softwares depend on it. I found
checkinstall much more robust.
yeah, but installing into /opt/package-version works on pretty much
all unix(like) OSs regardless of what package system you use. You're
right that it's not a good general solution but it's pretty handy for
small-scale installations (few programs and/or libs). Plus since
everything goes into one directory you're pretty sure that the rest of
the system is not affected (not sure how good is checkinstall in this
area, it tries to check what the install did but I'd rather have install
NOT touch the rest of the system, whether under supervision or not).
erik
11:19 p.m.
On 8/17/05, Erik Steffl <steffl(a)bigfoot.com> wrote:
I am not a
specialist of package management, but I know I installed
some big package from source with it (mono, for example), and it
worked flawlessly. I could remove it afterwards to fall back on an
official version.
I don't know if it depends on the package system, but with debian
packages, one package cannot overwrite a file from an other package,
except if you force it. That means for example that there is little
chance to destroy an existing package using a bleeding edge version
compiled from source and packaged by checkinstall.
Ideally, you should use an special user for testing big packages from
sources (to avoid destroying some configuration files).
David
? essentially I agree but why would uninstalling a program that was
installed into ONE directory under /opt be a problem? There were
obviously NO modifications to the system outside of that directory (I
usually make sure of it by not installing as root)
If you don't use the approach described earlier (each software in its
own directory), and use configure --prefix=/usr/local instead, after
you install several programs there, you will have many files in
/usr/local/bin, many files in /usr/local/lib, etc.... So you have no
ways to remove only one software. If you use one directory per
software, then the problem is different (except concerning the
configuration files which go under ~ ).
Basically,
installing from sources without the help of the package
manager is ok if nothing depends on what you are installing. It
quickly become unmanageable if other softwares depend on it. I found
checkinstall much more robust.
yeah, but installing into /opt/package-version works on pretty much
all unix(like) OSs regardless of what package system you use. You're
right that it's not a good general solution but it's pretty handy for
small-scale installations (few programs and/or libs). Plus since
everything goes into one directory you're pretty sure that the rest of
the system is not affected (not sure how good is checkinstall in this
area, it tries to check what the install did but I'd rather have install
NOT touch the rest of the system, whether under supervision or not).
11 Aug
11 Aug
6:44 p.m.
New subject: [linux-audio-user] Re: Gnome Wave Cleaner ...Got it! 8^)
Paul Davis wrote:
go back into the source code directory you
built+installed them from.
type:
make uninstall
plus lots more useful details...
and Fernando Lopez-Lezcano wrote:
You should have installed the development packages:
apt-get install libsndfile-devel fftw3-devel
They are part of the Planet CCRMA repository.
Wow, how easy was that? I just didn't realize I could use apt-get to
get these from CCRMA's repository since there was no example apt-get
command like there is for many of the other CCRMA packages. Now I know
to just try it. The worst that can happen is apt-get will just say
"Couldn't find package xyz".
So, for the record, here's what I did:
First I uninstalled the two library packages I had installed
in /usr/local per Paul's suggestion.
Then:
apt-get update
apt-get dist-upgrade
apt-get install libsndfile
libsndfile is already the newest version.
apt-get install libsndfile-devel
...lots of happy echoing...
apt-get install fftw3
fftw3 is already the newest version.
apt-get install fftw3-devel
...lots of happy echoing...
apt-get install libgnomeui
libgnomeui is already the newest version.
apt-get install libgnomeui-devel
...lots of happy echoing...
cd directory_where_gwc_tarball_was_unpacked
./configure --prefix=/usr
make
make install
gwc
It works!!!
Thanks Paul, Fernando and others who helped me get this figured out and
upgrade my brain AND my DAW. 8^)
Mike
Mike Jewell
One-Up Audio
7:31 p.m.
New subject: [linux-audio-user] Re: Gnome Wave Cleaner ...Got it! 8^)
tor, 11,.08.2005 kl. 13.44 -0700, skrev Mike Jewell:
Wow, how easy was that? I just didn't realize I could use apt-get to
get these from CCRMA's repository since there was no example apt-get
command like there is for many of the other CCRMA packages. Now I know
to just try it. The worst that can happen is apt-get will just say
"Couldn't find package xyz".
Check out apt-cache search
<packagename>
--
Frode Haugsgjerd
Norway
12 Aug
12 Aug
12:41 p.m.
New subject: [linux-audio-user] Re: Gnome Wave Cleaner ...Got it! 8^)
Yes, I now see that that is a cool way to see if a package is available
in my configured apt repositories and what the exact name is, etc.
Thanks,
Mike
On Thu, 2005-08-11 at 23:31 +0200, Frode Haugsgjerd wrote:
tor, 11,.08.2005 kl. 13.44 -0700, skrev Mike Jewell:
> Wow, how easy was that? I just didn't realize I could use apt-get to
> get these from CCRMA's repository since there was no example apt-get
> command like there is for many of the other CCRMA packages. Now I know
> to just try it. The worst that can happen is apt-get will just say
> "Couldn't find package xyz".
Check out apt-cache search <packagename>
2:10 p.m.
New subject: [linux-audio-user] Re: Gnome Wave Cleaner ...Got it! 8^)
On Fri, 12 Aug 2005 07:40:47 -0700
Mike Jewell <mj405(a)oneupaudio.com> wrote:
Yes, I now see that that is a cool way to see if a package is available
in my configured apt repositories and what the exact name is, etc.
Thanks,
Mike
You might also try synaptic. It has comfy search functionality (searches
in descriptions, too, etc..).
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
7041
days inactive
7047
days old
linux-audio-user@lists.linuxaudio.org
19 comments
10 participants
participants (10)
-
Bill Schottstaedt -
Bob -
David Cournapeau -
Erik Steffl -
Fernando Lopez-Lezcano -
Florian Schmidt -
Frode Haugsgjerd -
Mike Jewell -
Paul Davis -
Tracey Hytry