11 Oct
2010
11 Oct
'10
3:47 p.m.
On 10/11/10 14:33, fons(a)kokkinizita.net wrote:
That's 3 steps to much :) Besides: The issue with download is that the
next version number is not predictable. One needs to use a web-browser.
If it was a repository-checkout it'd be a one-time setup and just
calling a single 'pull & build' script afterward.
With git it's also easy to keep more than one repo: fi. a private with
all the small changes and a public where you only push out releases.
As for the 'sudo make install' - I'm quite reluctant to run that
command. Usually a 'make' suffices for testing.
..and if I can't wait until a tool makes it into Debian I roll my own
package for the meantime which provides for clean removal later on.
aaw right.
PREFIX=$HOME/usr make install # does not work but
make PREFIX=$HOME/usr install # does
Thanks for the hint.
I agree programmers should not be concerned about packaging. I was just
suggesting a few trivial changes that'll make live easier for PPL
packaging (either for distros or for their own benefit).
Anyway congratulations on these effects. I've only tested the reverb (I
don't [yet] have use for an autotuner) and it's brilliant.
I'm already looking forward to 'rack GUI'. Keep up the good work.
Cheers!
robin
PS.
Do you know or have any mirrors of kokkinizita.net? It'd be a pity if
all the great stuff on there would be lost in some accident.
On Mon, Oct 11, 2010 at 01:02:09PM +0200, Robin Gareus
wrote:
Well, as outlined below I am suggesting git/svn not as means for
concurrent/team development but for providing a canonical
version-independent URL that can be tracked for each of the projects.
A symlink 'zita-rev1-latest.tar.bz2' could provide the former, but one
won't be able to tell if there's any update without actually downloading
it or checking the mtime with HTTP-HEAD.
Are they also available from some repository
(svn, git,..)?
No. Most projects here are in svn and I'm exploring git
for a few of them. But the repositories are not nor will
ever be on a public server. There is no team development
on any of my projects, and I'm not planning any. watching
http://www.kokkinizita.net/linuxaudio/downloads/index.html
and upgrading apps there (which are not [yet] in common distributions)
by hand is kind of tiresome, even more so since your Makefiles do not
support 'make uninstall'.
Well... they are *source* packages. All it takes is download,
unpack, cd, sudo make install. The 'make remove' is a good idea,
I will be adding it to new releases.
The commonly used target (autotools) is "make uninstall"
(not "make remove")
OTOH, the installed size of
e.g. zita-rev1 (binary and *.png) is less than 100k, so little
is gained by removing it.
The motivation is not about recovering disk-space about being able to
keep the system clean.
Some of my earlier test|development machines|chroots quickly became
messed up with different versions in /usr/lib /usr/local/lib and after a
few weeks or month there was no hope but to re-install the thing.
You may know this situation.
The overhead of rolling custom packages is small compared to
re-installing or cleaning up by hand.
The nice thing
is that your Makefiles are pretty clean. using dh_make,
DESTDIR and quilt (change PREFIX to /usr)
you can define PREFIX on the make command line as well, there's
no need to modify the Makefile makes it easy
to debianize them for local packaging; however if
one could use git-buildpackage it would be even nicer.
Installer managed packages (taking care of dependencies etc.)
should be provided by the packagers of your distro, there's
no way I can do this. I don't even provide them for the distro
I use myself.