On 2007-10-29, matthew sporleder <msporleder@gmail.com> wrote:
> I understand that there are many packaging systems and this could be a
> burden for you, but it's a solution.  ;)

It's such a burden that it's really a non-solution. Contributors 
might provide those files, but they often go MIA, just like 
distributions' package non-maintainers. The major reason why 
I also don't provide autocrap is that I'm not going to touch 
that crap myself, and contributors too often go MIA. Same applies
to many other additions (such as the Xft patch that was the final 
drop for the license change): if I'm not interested in maintaining 
the feature when the contributor goes MIA, I'll not include it. 
I'm willing to include hooks and stuff for additional modules, 
however, but the FOSS herd seems to have something against modular 
code, and a hard-on for monolithic crap (such as the so-convoluted-
that-it's-practically-impossible-to-compile-anymore Linux kernel, not 
to even speak of the distros' practically unconfigurable initrds).

> I'm not sure what you mean by a megafreeze not caring about your time,
> etc, but you don't author or maintain the dependencies of building
> your package, so it's really the only reasonable way to ensure working
> builds.

I've written a rant about megafreeze distros elsewhere [1]. There's
nothing stopping decentralised packaging systems from having decent
dependency mechanism -- application directories and relocatable binaries
being essential towards that end, of course. ZeroInstall is the best 
attempt so far to my knowledge, but not good enough. I've written 
something about a system based on cryptographically identified 
capabilities [2]. The same system could be used to obsolete autocrap
(and although not decentralised, Nix [3] appears to have some useful
ideas).

  [1]: http://iki.fi/tuomov/b/archives/2007/03/03/T19_15_26/

  [2]: http://iki.fi/tuomov/b/archives/2007/07/16/T22_41_22/

  [3]: http://nix.cs.uu.nl/nixpkgs.html

-- 
Tuomo