[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [ardour-dev] ardour

On Thursday 12 September 2002 00:46, Paul Davis wrote:
> >> >work, helped by the autobuilders. Moreover, the build dependencies can
> >> >guarantee you the package will build fine if you try at home.
> >>
> >>=20
> >> !!NO THEY DO NOT!! why can people not understand this? there is no
> >
> >Why can't people understand that linking to a static library is BAD ?
> it poses some problems yes. but nothing as deep as programs that
> simply don't run correctly for completely inobvious reasons. i
> wouldn't advocate static linking for C, for example, but for C++, the
> situation is very difficult.

I was reading this thread and I understand both sides, that up front. I also 
believe that you, Paul Davis, are not happy with workarounds like static 
linking or maintaining a separate source-tree for required libs, just because 
it is 'not a solution'. Still, I understand your concerns and can imagine the 
problems that led you to start linking statically in the first place, 
diagnosing remote bogus computers by email is hard. Been there, done that.

Maybe I'd have a different approach to make both sides happy, Joe Clue and 
Joe Clueless: using a ports-like approach. The ardour team distributes it's 
sources plus a build-script. This script relies on the tarballs of required 
libs (which you could distribute in a version that you use and that is known 
to work). Joe Clueless would then just execute the build-script and get a 
version of ardour that runs. This is the foremost documented way to get 
ardour running, just because it is the easiest (though not most elegant). 
Apart from separating some parts, this is also mostly equivalent to what you 
already do.

 Joe Clue could call the same script with options like --use-sys-libsigc++ to 
not use the sigc++ supplied alongside but the one installed system-wide. That 
way, he doesn't have to use cludges like static linking as long as his system 
is not bogus. 
 The third build-option (which is in fact partially wrapped by the above 
script) is to use ./configure directly inside the ardour-sources. You can use 
things like --with-sigc++-path=/path/to/sigC++/install-location/ to have a 
fine-grained control over what libs are linked and the other autotools to 
control where the program is installed. 
 I did leave out one thing and that is static linking. I'm also doubting that 
that is really necessary as long as Ardour is installed in a separate 
location (which the mentioned script would do). In fact renaming/moving 
common libs and linking dynamically is in fact the same as static linking, 
except that you can't do things like toy around with LD_ environment 
 I'd also not encourage Joe Clueless to install programs system-wide, btw. 
For that, it might be worthwhile to then just transform the name of some libs 
(feasible via a sed command given to configure) so they don't mess up with 
the systems'. Speaking for Debian, I never found cases where it was 
worthwhile to work around its package management system and I experienced 
some cases where others broke their systems with that. 
 I know that for some cases it is advisable to run ardour as root or with 
root privileges, but even if you thus make root a regular user doesn't mean 
that root's playground must span the whole system.

BTW: IIRC, you had the problem with the C++ libs around one year ago. GCC 3 
was just in the stage of appearing there and not many had experience with it. 
Knowledge that there is something called ABI that might be incompatible is 
far more widespread today.

> >What we are speaking of here is building a Debian package, with a
> >maintainer. Users don't build the package, the maintainer and the
> >autobuilders do. The maintainer ensures that the package is built with
> >the compiler that was already used to build the libraries it depends on.
> >All of this guarantees the program will work, and with *dynamic*
> >libraries, while the user never has to build the software. If the user
> >doesn't build the software himself, all the issues you describe will
> >never appear.
> *if* this is all completely true, then i *am* happy with the idea of
> debian packages dynamically linked against other C++ libraries.

It is. You can expect your packages to be built by someone that knows what 
they are doing. Furthermore it will remain in testing/unstable for quite some 
time which is a distribution that is only for advanced users. Those users 
know that they are supposed to report bugs to the maintainer and not to 
upstream or even fix them themselves.

> however, it will mean not be acceptable for a source package, and it
I'm not totally sure, but before misunderstandings come up, let me say that 
there are so-called source-packages for Debian. Those are mainly used by the 
autobuilders but can also be used by Joe Clue:
$ apt-get source ardour
$ cd ardour-x.y.z
$ dpkg-buildpackage -us -uc

YMMV, but I consider those a secure method. Especially since those packages 
_where already successfully used_ for building a package, Joe Clue will know 
that it is his fault (or his system's) if something breaks and not bugger 

> i would like to see a debian package of ardour, i really would. but
> the claims i have read about "complaints will go to the maintainer
> first" don't convince me, and neither does anything you have written
> so far, that such a package would not result in many emails to me
> and/or the ardour email lists talking about strange behaviour by the
> program on someone's machine. i could punt this back down to the
> maintainer, i suppose.

Hey, have confidence. :)

Reply to: