Excerpts from Robin Gareus's message of 2010-10-11 15:47:43 +0200: > On 10/11/10 14:33, [email protected] wrote: > > On Mon, Oct 11, 2010 at 01:02:09PM +0200, Robin Gareus wrote: > > > >> 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. > > 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. > > >> 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. > > 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. > > > 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 > > aaw right. > PREFIX=$HOME/usr make install # does not work but > make PREFIX=$HOME/usr install # does > > Thanks for the hint. > > >> 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. > > > > 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).
The only thing I could wish for is a short announcement mail in case of new versions. This way I'll update the packages in a more timely fashion, otherwise some user of the package needs to tell me that there's an update available, which can take weeks. The actual time for me to update a package is usually 2 minutes. I like short changelogs too. Well, no big deal, just my little packagers wishlist. _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
