[LAD] Some new things to play with

Philipp Überbacher hollunder at lavabit.com
Mon Oct 11 14:38:53 UTC 2010

Excerpts from Robin Gareus's message of 2010-10-11 15:47:43 +0200:
> On 10/11/10 14:33, fons at kokkinizita.net 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.

More information about the Linux-audio-dev mailing list