On Tue, Dec 21, 2010 at 7:11 AM, Arve Barsnes <arve.barsnes@xxxxxxxxx> wrote:
> At this time I really think it should be the packager's
> responsibility to respect the developer's wishes in regards to their
> software. Software that isn't even released yet, but that they
> graciously have decided to develop on a publicly accessible repo.
> Anyone can benefit from build scripts, but with the situation as it
> is, it should be unnecessary to put additional work on Paul because
> the wrong people get access to those scripts.
We have a winner!
> Having the PKGBUILD now doesn't change the number of "try" users.
There are bound to be casual Ubuntu/Debian/Fedora users who have
figured out how to get ardour3 via Subversion, simply because they're
excited. There's no solution to this.
This isn't the problem though. Those users that go through that
process have demonstrated some dedication already in time invested in
order to compile, and are that much closer to being a benefit to the
community at large by providing useful feedback in debugging. In
order for them to 'figure out' the process chances are at some point
they did some reading and research, far more than is required by the
buildscript process. If Ubuntu had a package of A3 in its repos, it
would be just as much of a problem for that exact same reason.
Once you put this time in once, doing so a second time is a
cakewalk(And only needed if on a different machine or you have
reinstalled most of your base system in many cases) and a much smaller
investment in time. A third and fourth are even less. The people that
provide useful debugging information, even after Ardour is released
are the people that put in that effort to build a debug version.
On Linux I was a Gentoo person, and heavy user of the portage ebuilds
for SVN access to Ardour. It was nice, but I ran into problems on
occasion that I couldn't answer only because I hadn't built it myself
and didn't know every step of the relevant process what had happened.
On OS X I build everything by hand(And if you think doing this on
Linux is hard, you ain't seen nothing yet till you try to do it on OS
X Snow Leopard). I have often considered writing scripts to automate
this, but at this time have not for a variety of reasons, but
primarily because this way I know exactly what version of what libs
are involved and Paul can tell me exactly what version I need to be on
for appropriate fixers not only in Ardour, but in other libs as well
that he is far more familiar with than I am and has submitted patches
to for problems discovered by Ardour.
But here is the other half of the matter that Paul alluded to but did
not go into detail on. A3 is in heavy development and for the testers
being sought after, installation is not a common occurance. In fact
it is recommended NOT to install A3 while testing, because often times
you may need to test a patch on your codebase, your own local
checkout, before it is committed to SVN. You can't do that extremely
easily on an installed system, and A3's code is specifically set up to
run from the build directory via scripts for this exact purpose,
debugging and bug reporting.
So the short of it is, consider the building the source by hand a
filter to make sure you can and should be doing so. If you can and
should be doing so, chances are you could write the buildscript
yourself to check out A3's code and build it in a day at most(A few
minutes if you are a coder really), with all testing. It isn't that
difficult, the dependency handling is the most difficult and the
benefit to distribution systems, but noone is saying you can't write
your own package to do exactly that, just not to distribute it at this
time is the request.
Seablade
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
