[PlanetCCRMA] FW: [Ardour-users] Ardour/jack totally broken on two systems now using jack 0.39.0...

[Mark Knecht]

Fernando,
   synaptic did remove the jack helper stuff, but not jack itself. I had to
use rpm -e to do that. I just don't know why. synaptic didn't give any
reasons...

   I think your words about RPMS are very wise. Personally I would like to
stick with RPMs most of the time. The system, overall, works better for me
when I do. Problems come up, at times though, with these apps that aren't so
stable and are changing faster than you can keep up with there. And, yes,
the RH model vs. other distribution model for directories doesn't help. But
I think we can learn how to handle it, or at least I hope so.

   The other thing I'm running into is there isn't only a standard
"./configure, make, make install" cycle, but also "./autogen.sh,
./configure, make, make install" and also "./autogen.sh, make, make install"
cycle, so I'm seldom sure that I'm really building things correctly! The
README's and INSTALL files get out of date, or apply to some other
distribution, so you get a lot of problems going that way also. It's fine
for real software people, but it's a problem for me. I just want it to work.
;-)

   The problems of being on the leading edge...

Thanks,
Mark

-----Original Message-----
From: Fernando Pablo Lopez-Lezcano [mailto:nando@ccrma.Stanford.EDU]
Sent: Thursday, October 10, 2002 10:25 AM
To: Mark Knecht
Cc: PlanetCCRMA (E-mail)
Subject: Re: [PlanetCCRMA] FW: [Ardour-users] Ardour/jack totally broken
on two systems now using jack 0.39.0...


>    What's the preferred method to remove packages that were installed with
> apt-get?

>From the command line you can either use rpm (as in "rpm -e package_name")
or apt-get ("apt-get remove package_name"). Rpm will warn you if the
package is needed by others, it would not be good to bypass that and
remove it anyway :-) Apt-get will tell you which other packages will be
removed as well so that dependencies are clean and prompt you on whether
to proceed.

I have not tried synaptic for package removal. You probably have to select
the package, click "remove" and then at some point "execute" the removal.

> The PlanetCCRMA process and the straight compile process are
> putting jack in different places and this seems to be causing problems for
> me as I am trying to run a newer version of jack.

I'm using a "/usr" prefix as that is the default for all other redhat
packages. Some (most?) programs by default select "/usr/local" as the
prefix. You can change where the package will be installed by adding a
"--prefix=/usr" argument to the configure process, the make install will
install with /usr as the prefix (that is what I'm doing in the rpm spec
file).

So now let's assume that you go ahead and rebuild jack with a plain
configure, make, make install cycle and select "/usr" as the prefix,
without removing the existing jack rpm first (because if you do you will
have to also remove all the jack aware applications so that dependencies
are not broken - remember, apt-get will not work on a system with broken
dependencies and that is good).

That may (will?) break existing applications if the library version number
or api compatibility of the newer jack have changed. That is, a plain
configure, make, make install will check that jack can be installed (ie:
all libraries and programs it needs are there), it will definitely not
check if _other_ existing programs in the system that need jack can work
with the newly installed jack libraries.

The only proper solution (IMHO) is rebuild a jack rpm with the newer
version and deal with all the dependency problems properly. That is if you
want stability. You can always test things by "writing over" the existing
rpm with a make install, with the proviso that applications might stop
working. You then can make uninstall the new package and force a reinstall
of the original rpm if you want things to be back to where they were.

There is some very strong advocacy from time to time for just using
configure, make, make install for all installs and strong criticism of
packaging systems (not you, of course :-) Yet nobody talks much about the
fact that the configure method has serious maintenance problems, it does
not mantain consistency with already installed programs, that is, a
perfectly legal install can break already installed programs. Of course if
you _know_ what you are doing at the dependency level you can get away
with it, or if your system is one of a kind and you never have to
reinstall from scratch then it is fine (or if your library is used by one
program only and you update the program and library at the same time).

-- Fernando