11 Oct
2010
11 Oct
'10
4:38 p.m.
Excerpts from Robin Gareus's message of 2010-10-11 15:47:43 +0200:
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).
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.
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.